Compilers & Programming Language Theory MCQ

Explanation

Compiler phases: Lexer (tokens) → Parser (AST) → Semantic Analysis (type checking) → IR generation → Optimization → Code generation. A linker is a separate tool.

Explanation

The lexer (scanner) uses regular expressions/DFAs to recognize tokens: IF, id("count"), INT_LIT(42), PLUS(+). Whitespace and comments are discarded. Produces a token stream for the parser.

Explanation

Tokens: keyword (if, while), identifier (x, myVar), literal (42, "hello"), operator (+, ==), delimiter (;, {). The token stream abstracts away whitespace and enables grammar-based parsing.

Explanation

Parse trees show every grammar production used. The AST (abstract syntax tree) simplifies this by removing non-informative nodes and keeping only the essential structure.

Explanation

ASTs remove noise from parse trees: no redundant parentheses, semicolons, or intermediate grammar symbols. Compilers, interpreters, linters, and refactoring tools all work on the AST.

Explanation

CFGs define programming language syntax: statement → if ( expr ) statement | for ( expr ; expr ; expr ) statement | ... Parser generators (yacc, ANTLR, Bison) automatically build parsers from CFG specifications.

Explanation

Compiler (C, Rust): translate to native code, no runtime translator needed. Interpreter (Python, Ruby): translate+execute per statement. JIT (Java, JS V8): compile hot paths at runtime for speed with interpreter flexibility.

Explanation

Semantic analysis: type checking (can't add int + string), scope checking (variable declared before use), function signature checking. Builds and queries the symbol table. Reports errors before code generation.

Explanation

Symbol tables support declaration and lookup of identifiers. Scoped symbol tables handle nested scopes. Attributes stored: type, size, offset, parameter list for functions. Central to type checking and code generation.

Explanation

IR (three-address code, SSA, LLVM IR, JVM bytecode) decouples the front-end (language-specific) from the back-end (machine-specific). Optimizations on IR benefit all languages and targets.

Explanation

Register allocation: choose which variables live in registers (fast) vs. memory (slow). Graph coloring-based allocation: interference graph colors = registers. Spilling: variable that doesn't fit goes to stack.

Explanation

Instruction selection: IR multiplication might map to MUL, or shift+add if multiplying by power of 2. Tree-pattern matching (IBURG, SDISel) finds optimal instruction sequences.

Explanation

Recursive descent: parseExpr() calls parseTerm() calls parseFactor(). Handles LL(k) grammars. Easy to implement manually, extends to error recovery. Used in GCC's front-end, LLVM Clang.

Explanation

LL parsers: predictive, use lookahead to predict which production to apply. LR parsers: build rightmost derivation in reverse, handle larger grammar classes. GCC uses recursive descent; LR is used by Yacc/Bison.

Explanation

Shift-reduce conflict: in "if (cond) if (cond) stmt else stmt" — the else might belong to either if (dangling else). Resolved by convention (else matches nearest if) or grammar disambiguation.

Explanation

DCE: unreachable code (after return, always-false conditions) and dead stores (x=5; x=10; — first assignment unused). DCE interacts with other optimizations; IR in SSA form makes DCE trivial.

Explanation

Constant folding: 3+4 → 7 at compile time. Combined with constant propagation (replace uses of constant variables with their values). Eliminates unnecessary computation.

Explanation

Inlining eliminates call overhead (save/restore registers, jump, return). More importantly, it exposes the callee's code to surrounding optimizations. The compiler decides when inlining is beneficial.

Explanation

Loop unrolling: for(i=0;i<8;i++) body → body body body body body body body body (8 copies, no loop). Reduces branch overhead, increases ILP. Downside: larger code, more register pressure.

Explanation

SSA (Rosen et al., 1988): x₁=...; x₂=...; y=x₁+x₂. φ-functions at join points: x₃=φ(x₁,x₂) depending on control flow. Makes data flow obvious, simplifies optimizations (DCE, constant propagation, LICM).

Explanation

Hindley-Milner type inference (ML, Haskell): unification-based algorithm deriving principal types. The most general type is inferred without annotations. C++ template deduction and Java generics use related techniques.

Explanation

Reduce/reduce conflict: two different productions can be applied to the same input. More serious than shift/reduce conflicts. Indicates grammar ambiguity or LR(1) grammar issues requiring grammar restructuring.

Explanation

Runtime systems provide: garbage collection (Java, Python, Go), dynamic dispatch, stack unwinding (exceptions), reflection, bounds checking. C has minimal runtime; Java's JVM is a full runtime environment.

Explanation

C/Rust: AOT compiled → fast native code. Python: interpreted at runtime → flexible but slower. Java/JS: bytecode/IR + JIT compilation at runtime → combines portability with near-native speed after warmup.

Explanation

Linker: takes .o files, resolves symbols (function calls, globals), combines into executable or library. Static linking embeds libraries; dynamic linking uses shared libraries (.so/.dll) loaded at runtime.

Explanation

C++ allows overloaded functions (same name, different parameters). Linkers work on unique names, so compilers encode: foo(int,float) → _Z3fooif. extern "C" disables mangling for C interop.

Explanation

Language VMs execute bytecode, providing: portability (write once, run anywhere), managed memory, security sandboxing, and dynamic optimization (JIT). Different from system VMs (VMware) which virtualize hardware.

Explanation

Java bytecode (.class files), Python bytecode (.pyc), .NET CIL are examples. Platform-independent: the VM interprets/JIT-compiles bytecode for each architecture. More portable than native code.

Explanation

GC algorithms: reference counting (Python — cycles need cycle collector), mark-and-sweep (traverse from roots, free unreachable), copying (compact live objects), generational (most objects die young). Trade: simpler programming vs. GC pauses.

Explanation

Tail call: the last action of a function is a call with no remaining work. TCO replaces call+return with a jump, reusing the stack frame. Enables recursion in place of loops without stack overflow. Mandated in Scheme, supported by Kotlin, optional in others.

Explanation

Type systems: static (checked at compile time: Java, Rust, Haskell), dynamic (checked at runtime: Python, JavaScript), gradual (both: TypeScript, mypy). Strong typing prevents implicit conversions; weak allows them.

Explanation

Parametric (List<T> works for any T), ad-hoc (+ works for int, float, string via overloading), subtype (Cat behaves as Animal). Strachey's 1967 classification. Related: type classes (Haskell), traits (Rust).

Explanation

Closures capture variables from enclosing scope. In Python: def make_adder(x): return lambda y: x+y. The returned lambda closes over x. Used for callbacks, higher-order functions, and state encapsulation.

Explanation

Currying (Haskell Curry): add(3)(4) instead of add(3,4). In Haskell, all functions are curried by default. Enables partial application and function composition. Lambda calculus theoretically needs only single-argument functions.

Explanation

Pattern matching (Haskell, Rust, OCaml, Scala, Python 3.10): match list { [] -> 0 | [x] -> 1 | x::xs -> 1+length(xs) }. More expressive than if/else for algebraic data types.

Explanation

Monads: Option (maybe null), List (non-determinism), IO (side effects), State (threading state). Operations: return (wrap value), bind (>>=, chain computations). "A monad is just a monoid in the category of endofunctors."

Explanation

Lambda calculus (Church 1932): λx.x is the identity function. Application: (λx.x+1) 5 = 6. β-reduction: (λx.e₁) e₂ → e₁[x:=e₂]. Church-Turing thesis: LC and TMs compute the same functions. Foundation of functional programming.

Explanation

JIT (Java HotSpot, V8 TurboFan, PyPy, LuaJIT): detect frequently executed code (hot spots), compile to optimized native code at runtime. Provides interpreter flexibility + near-compiled performance after warmup.

Explanation

Memoization makes pure functions fast: fib(40) goes from exponential to O(n) with memo. Languages use it for lazy evaluation (Haskell thunks cache results on first evaluation) and dynamic programming.

Explanation

A program can be syntactically valid (well-formed according to the grammar) yet semantically wrong (e.g., adding a string to a boolean). Compilers check syntax via parsing and semantics via type checking and other static analyses.

Explanation

HM (Algorithm W): unification variables, constraint generation, unification to solve constraints. Infers ∀a. [a] → Int for length :: [a] → Int. Decidable for Hindley-Milner; undecidable for System F (full second-order).

Explanation

CPS: factorial(n, k) where k is the continuation (what to do with the result). Every call becomes a tail call. CPS enables: trampolining (space-efficient recursion), call/cc, and is the target of CPS transforms in compilers.

Explanation

Abstract interpretation (Cousot 1977): instead of executing on concrete values, run on abstract values (signs: +/-/0, intervals [l,u]). Sound overapproximations: if abstract execution is safe, concrete execution is safe. Used in Astrée (Airbus), Frama-C.

Explanation

Static (lexical) scoping (most languages): name resolution at compile time from definition site. Dynamic scoping (older Lisps, Perl with local): name resolution at runtime from caller chain. Static is predictable; dynamic enables implicit parameter passing.

Explanation

Dependent types (Coq, Agda, Lean, Idris): types are first-class values. "length-2 list" is a type. Addition with dependent types: add : Nat → Nat → Nat with proof of commutativity. Programs-as-proofs (Curry-Howard).

Explanation

Curry-Howard: A→B in logic corresponds to function type A→B in types. ∧ corresponds to product types. ∨ to sum types. A proof of a proposition is a program of the corresponding type. Foundation of proof assistants.

Explanation

Effect systems: Haskell's IO monad, algebraic effects (Koka, Eff), capability systems. Rust's Send/Sync track thread safety. Effect handlers (Multicore OCaml) provide modular non-local control flow with type tracking.

Explanation

Dataflow analysis: live variable analysis (which variables are needed after each point), reaching definitions (which assignments may reach a use), available expressions. Uses fixed-point iteration over the control-flow graph.

Explanation

Alias analysis: if p and q may alias, the compiler cannot reorder or optimize p→ writes and q→ reads independently. Must-alias (always), may-alias (possibly), no-alias (never). Key to enabling vectorization and load/store reordering.

Explanation

LICM: for(i=0;i<n;i++) x=a*b+c; → x=a*b+c; for(i=0;i<n;i++). The a*b+c doesn't change each iteration. Requires proving the computation is loop-invariant and loop always executes. Reduces N iterations to 1.

Explanation

Strength reduction: mul by power of 2 → shift. In loops: for(i=0;i<n;i++) sum += a[i*stride] → track running offset. Induction variable strength reduction converts multiplications to additions.

Explanation

Devirtualization: if the compiler proves obj is always a Foo, it can replace obj->method() (vtable lookup + indirect call) with Foo::method() (direct call). Enables inlining and eliminates vtable overhead.

Explanation

If the compiler proves obj never escapes a method (no external references), it can: allocate on stack (no GC), eliminate synchronization (no sharing). JVM HotSpot, GraalVM perform escape analysis for lock and allocation elision.

Explanation

Partial evaluation (Futamura projections): specialize an interpreter for a specific program → compiled code. The Futamura projections show compilers can be derived from interpreters by partial evaluation — deep connection between the two.

Explanation

CBV (C, Java, Rust): argument evaluated before function call. CBR (C++ &, pass address): modifications affect caller. CBN/CBNeed (Haskell): evaluate when needed, memoize result. Lazy evaluation enables infinite lists but makes space analysis harder.

Explanation

Monomorphization (C++ templates, Rust generics): vector<int> and vector<string> generate separate compiled code. Zero overhead since no type erasure. Tradeoff: binary size. Java/Go use type erasure instead.

Explanation

Deforestation (Wadler 1988): map f . filter p . map g → single traversal without intermediate lists. Stream fusion in GHC: build/foldr or stream/unstream pairs enable the GHC optimizer to fuse pipelines automatically.

Explanation

Java generics: List<String> and List<Integer> are the same type at runtime (List). Type casts are inserted at call sites. Cannot do instanceof List<String>. C++ templates and C# generics preserve type info (reification).

Explanation

Trampoline: each tail call returns a thunk instead of calling directly. A loop executes thunks iteratively. Enables TCO in languages without native TCO (JVM, .NET). Space: O(1) per mutual tail call.

Explanation

LL(1) parsing tables are constructed from FIRST sets (tokens that can start a production) and FOLLOW sets (tokens that can follow a non-terminal). With one token of lookahead, the table gives a unique production to apply, avoiding backtracking.

Explanation

A rule like expr -> expr + term makes parseExpr() immediately call parseExpr() again with no token consumed, looping forever. The standard fix is to rewrite the grammar to be right-recursive or to use an iterative loop with left-factoring.

Explanation

LR(0) items carry no lookahead, so many practical grammars produce conflicts. LR(1) attaches a lookahead symbol to each item, letting the parser decide whether to reduce based on what token follows, resolving many of those conflicts at the cost of larger tables.

Explanation

Dataflow frameworks model facts (e.g., sets of live variables) as lattice elements ordered by precision. The transfer functions are monotonic and the lattice has finite height, so repeatedly applying them from an initial approximation must reach a fixed point.

Explanation

CSE finds expressions like a*b appearing in multiple places whose operands have not changed between occurrences, computes the value once, and reuses it — reducing redundant arithmetic, memory loads, or function calls.

Explanation

Block A dominates block B if every path from the entry to B passes through A. Dominator trees identify natural loops and determine where SSA phi-functions must be inserted (at dominance-frontier nodes).

Explanation

FOLLOW(A) contains every terminal that can appear immediately after A in some sentential form (plus end-of-input where applicable). It is essential for filling table entries for productions that derive the empty string.

Explanation

A one-pass design struggles with forward references (using a label or symbol before its definition appears). A first pass builds a complete symbol table; the second pass then resolves all references and generates correct code or addresses.

Explanation

Languages with first-class functions (JavaScript, Python, Haskell, Rust closures) treat functions as ordinary values, enabling higher-order functions such as map, filter, and reduce, and patterns like callbacks and combinators.

Explanation

Most imperative languages are eager: let x = expensiveCall() runs immediately. Haskell is lazy by default: a binding creates a thunk that is only forced when its value is demanded, which allows infinite data structures but complicates reasoning about memory usage.

Explanation

Three-address code (e.g., t1 = a * b; t2 = t1 + c) breaks complex expressions into uniform, simple steps. Its regular structure makes it easy to apply dataflow analyses, perform optimizations, and translate to target machine instructions.

Explanation

Basic blocks are the nodes of a control-flow graph: control enters only at the first instruction and leaves only at the last (a branch or jump). This property lets compilers analyze and optimize execution paths systematically.

Explanation

Without precedence rules, "2 + 3 * 4" could parse multiple ways. Operator precedence parsing uses precedence and associativity tables (or precedence climbing) to build the correctly grouped expression tree efficiently.

Explanation

The "generational hypothesis" observes that most allocated objects become garbage shortly after creation. By focusing collection effort on the young generation (which is small and has high garbage density), collectors like those in the JVM and .NET reduce overall pause times significantly.

Explanation

Mark-and-sweep can leave the heap fragmented since dead objects are freed in place. Copying collectors (e.g., semispace) relocate live objects to a contiguous region, which compacts memory and makes allocation a simple pointer bump, at the cost of needing extra space and updating references.

Explanation

In Python or Ruby, a function that calls obj.read() will work with any object providing a compatible read method, regardless of its class hierarchy. The check happens dynamically at the call site rather than through static type declarations.

Explanation

Calling conventions (e.g., System V AMD64 ABI, cdecl, stdcall) define which registers hold arguments, who cleans up the stack, and which registers a callee must preserve. Without an agreed convention, code from different compilers or languages could not call each other reliably.

Explanation

Statically typed OOP languages resolve dynamic dispatch through per-class vtables built at compile time. Dynamic-language runtimes (V8, Smalltalk VMs) instead use inline caches that remember which method was found for a given receiver shape, avoiding repeated lookups for monomorphic call sites.

Explanation

When two branches each assign a different SSA version of a variable (x1 in one branch, x2 in the other), a phi-function x3 = φ(x1, x2) at the join point picks the correct version based on the predecessor block, preserving the single-assignment property while merging control flow.

Explanation

In lazy languages such as Haskell, binding a name to an expression does not immediately compute it; instead a thunk wraps the expression. The first time the value is demanded, the thunk is evaluated and, in call-by-need semantics, the result replaces the thunk so subsequent uses are free.

Explanation

Bidirectional type checking (used in TypeScript, Swift, and many academic systems) propagates expected types downward (checking) and computes types upward from the leaves (synthesis). This combination handles higher-rank polymorphism and ambiguous literals more gracefully than algorithms relying purely on one direction.

Explanation

HM let-polymorphism: let f = λx.x in (f 1, f "a") type-checks (f is polymorphic). But (λf. (f 1, f "a")) (λx.x) doesn't (lambda parameters can't be polymorphic in HM — rank-2 types needed).

Explanation

Intersection types (A ∩ B): the term has both behaviors. f : (Int→Int) ∩ (String→String) can specialize its behavior. More expressive than union. Used in TypeScript (A&B), Scala, and type theory for overloading.

Explanation

Nominal (Java, C#): Dog and Cat are different types even if they have the same fields. Structural (Go interfaces, TypeScript): any type with matching methods satisfies the interface. Structural is more flexible; nominal catches more accidental coincidences.

Explanation

Gradual typing (Siek & Taha 2006): dynamic type is a supertype of all types. Boundaries between dynamic/static code insert runtime type checks (casts). TypeScript, mypy, gradual Racket. Blame tracking assigns casts to parties.

Explanation

Attribute grammars (Knuth 1968): synthesized attributes (computed from children: type, value), inherited attributes (from parent/siblings: expected type, environment). Specify type checking and code generation as grammar attribute equations.

Explanation

Operational semantics (Structural, Natural/Big-step, Small-step): inference rules defining transition relation ⟨e,σ⟩→⟨e',σ'⟩ or ⟨e,σ⟩⟹⟨v,σ'⟩. Mechanically verifiable. Used in language specifications (ECMA, JVM) and proof assistants.

Explanation

Denotational semantics (Scott-Strachey): [[if b then e1 else e2]] = if [[b]] then [[e1]] else [[e2]]. Compositional: meaning of compound expression from meanings of parts. Requires domain theory (Scott domains) for recursive definitions.

Explanation

C++: non-virtual methods are early bound (direct call). Virtual methods are late bound (vtable lookup). Java: all non-final methods are late-bound. Late binding enables polymorphism; early binding enables inlining.

Explanation

B-B encoding (1985): List<A> = ∀R. R → (A → R → R) → R. Represents nil/cons as functions. Enables ADTs in pure System F. Related to Church numerals, continuation-passing. Scott encoding is an alternative.

Explanation

System F (Girard/Reynolds): polymorphic lambda calculus with ∀. System Fω adds kind system: ⋆ (types), ⋆→⋆ (type constructors), (⋆→⋆)→⋆ (higher-kinded). Haskell uses a simplified System Fω-like core.

Explanation

Linear types (Girard's linear logic, Rust's ownership): a linear resource must be used exactly once. Prevents: use-after-free (can't use moved value), double-free (only one owner), aliasing violations. Rust implements linear types for memory safety.

Explanation

Y combinator: Y f = f (Y f). Enables defining recursive functions without named recursion. In call-by-value languages, use Z combinator (strict version). Y demonstrates lambda calculus has fixed points, enabling computation of all recursive functions.

Explanation

Landin (1964): SECD machine gave operational semantics to Algol-like languages. His J-operator (predecessor to call/cc) enabled first-class jumps. Foundation for understanding how control operators fit into denotational semantics.

Explanation

Algebraic effects (Bauer & Pretnar 2015, Koka, Multicore OCaml, Effekt): effects are declared as operations (raise, yield, state.get). Handlers provide implementation. Allows replacing one handler with another for testing — more modular than monads.

Explanation

CompCert (Leroy 2006): verified in Coq. Proof: for any C source S and compiled code C, if S terminates with value v, then C terminates with value v. Used in aviation and automotive safety-critical software (DO-178C).

Explanation

Wasm formal spec (Haas et al., PLDI 2017): structural typing for operand stacks, explicit type annotations, structured control flow. Theorem: well-typed Wasm programs are safe (no undefined behavior, type errors, or stack overflows).

Explanation

Hindley-Milner has principal types: the inferred type is the most general — any other valid type is a substitution instance of it. System F lacks principal types (type inference is undecidable). Principal types ensure type inference is well-defined.

Explanation

CPS transform: f(x) becomes λk.k(f_cps(x)). The continuation monad Cont r a = (a→r)→r has bind that composes these exactly. callCC in the monad corresponds to grabbing the current continuation. Equational connection between operational and denotational semantics.

Explanation

The canonical LR(0) construction starts from the item S' -> .S, applies closure (adding items reachable via epsilon-like derivation) and goto (advancing the dot over a grammar symbol) until no new item sets appear. Each item set becomes a parser state, and transitions between them form the LR automaton that drives shift/reduce decisions.

Explanation

Unifying a with a -> a would require a to equal a function whose argument is itself, an infinite type with no finite representation. The occurs check rejects such unifications; skipping it (as some implementations do for performance) can cause non-termination or unsound "infinite type" results.