Reflective Study Guide

Programming Paradigms & Language Concepts

Introduction
------------
This guide is meant to strengthen your conceptual grasp of programming‑language
principles while nurturing durable skills—critical thinking, creativity, and
collaboration. It is organised by lecture topic so that you
focus on broad, transferable ideas instead of memorising specific questions.
Use the “Reflective stretch” prompts and the final habit‑building table to
challenge yourself and your peers.

--------------------------------------------------------------------
1. Language Design & Evaluation
--------------------------------------------------------------------
* Trade‑off mindset – every feature balances goals such as readability,
writability, reliability, performance, and orthogonality.
* Paradigm palette – imperative, functional, logic, and OO each foreground
distinct abstractions that fit different problem domains.
* Execution models – compilation vs interpretation (and hybrids) shape latency,
portability, and feature sets (macros, reflection).
* Type‑system stance – static vs dynamic typing decides where correctness is
enforced and which polymorphisms feel natural.
* Value vs reference semantics – copy versus alias choices ripple into API
design, memory safety, and optimisation opportunities.
Reflective stretch: map two languages you know against each design goal; note
where one excels and the other falters.

--------------------------------------------------------------------
2. Lexical Structure, Scanning & Regular Expressions
--------------------------------------------------------------------
* Why separate a scanner? – cleanly divides tokenisation from parsing and
enables IDE tooling.
* Character sets & token kinds – Unicode vs ASCII affects identifier policy and
internationalisation.
* Longest‑match & priority rules – deterministic automata let “>=” outrank “>”.
* Regex power & limits – great for linear patterns, insufficient for nesting.
* Error‑recovery philosophy – permissive IDEs vs fail‑fast compilers.
Reflective stretch: write a mini‑lexer in Python for a toy language and observe
how DFA states eliminate ambiguities.

--------------------------------------------------------------------
3. Grammars, Parsing & Abstract Syntax
--------------------------------------------------------------------
* CFGs as contracts – they declare which strings are well‑formed independent of
meaning.
* Ambiguity & precedence engineering – ambiguous grammars impede deterministic
 compilation; precedence rules or refactors resolve conflict.
* AST vs parse tree – compilers compress parse trees into ASTs for analysis.
* EBNF & metalanguages – shorthand (* + | ?) reduces rule noise.
* Parser strategies – top‑down (LL) vs bottom‑up (LR) affect error quality and
tooling (ANTLR, Bison).
Reflective stretch: draw both left‑ and right‑most derivations for any arithmetic
expression, then write a visitor that evaluates the AST.

--------------------------------------------------------------------
4. Names, Scope & Environments
--------------------------------------------------------------------
* Binding‑time dimensions – name/entity association may happen at load‑time,
compile‑time, or link‑time.
* Static vs dynamic scope – static scope closes over definition frames;
dynamic scope ties lookup to the call stack.
* Frames & lookup chains – nested blocks create activation records; lexical
lookup walks outward through parents.
* Parameter‑passing spectrum – value, reference, result, value‑result, name;
each balances aliasing risk and performance.
* Modularity impact – clear scope rules permit local reasoning; unclear rules
cause “action at a distance.”
Reflective stretch: rewrite one function under each passing mode and predict the
visible side‑effects; verify in a REPL.

--------------------------------------------------------------------
5. Control Flow, Sequencing & Short‑Circuit Semantics
--------------------------------------------------------------------
* Structured‑programming legacy – if/while/for replaced goto to reduce
cyclomatic complexity.
* Short‑circuit evaluation – logical &&/|| couples order with side‑effects.
* Dangling‑else & syntactic hazards – grammar decisions influence readability.
* Alternatives to explicit control – higher‑order functions, comprehensions,
and reactive streams shift focus from “how” to “what.”
Reflective stretch: trace a compound conditional in three languages to see which
sub‑expressions actually execute.

--------------------------------------------------------------------
6. Functions, Recursion & Algorithmic Reasoning
--------------------------------------------------------------------
* First‑class & higher‑order status – treating functions as data enables
callbacks, decorators, and command patterns.
* Activation‑record anatomy – understanding return PC, locals, and temporaries
clarifies stack traces and tail‑call optimisation.
* Tail recursion vs iteration – equivalent with TCO; choice depends on clarity
and proof style.
* Folds and composition – fold‑left/right turn structural repetition into
reusable abstractions.
* Complexity reasoning – recurrences translate naturally to Big‑O estimates.
Reflective stretch: convert an iterative algorithm (e.g., list reversal) to tail
recursion, benchmark with and without TCO, and analyse memory profiles.

--------------------------------------------------------------------
7. Streams, Laziness & Program Algebra
--------------------------------------------------------------------
* Streams as delayed lists – a stream pairs a head with a thunk for the tail,
enabling infinite structures.
* Compositional operators – stream‑filter/map/zip express *what* while deferring
*when*.
* Reasoning laws – laziness plus purity allows algebraic rearrangement of
pipelines.
* Performance trade‑offs – laziness may save work but can leak memory if thunks
pile up.
* Concurrency hooks – stream abstractions generalise naturally to reactive
event pipelines (e.g., Rx).
Reflective stretch: implement the Sieve of Eratosthenes as a prime‑number
stream; insert debug prints to observe thunk forcing.