The functional paradigm: functions as first-class values, pure functions and referential transparency, immutability and the avoidance of side effects, the use of recursion instead of iteration, and how functional differs from imperative programming.

Pure function (up to 2 marks): a function whose output depends only on its input arguments and which has no side effects (it does not change any external state or rely on anything outside its parameters); given the same inputs it always returns the same output.

Referential transparency (up to 1 mark): the property that a function call can be replaced by its result value without changing the program's behaviour, which follows from purity.

Benefits (up to 2 marks): easier to test and reason about (output depends only on inputs); easier to run in parallel (no shared mutable state to conflict); results can be cached (memoised); fewer bugs from unexpected state changes.

Markers reward the same-input-same-output, no-side-effect definition of purity, the replace-call-with-result idea of referential transparency, and two valid benefits.

Imperative (up to 2 marks): programs are sequences of statements that change the program's state (variables) step by step; repetition is usually achieved with loops; side effects (changing variables, input/output) are normal.

Functional (up to 2 marks): programs are built by composing functions that avoid changing state; data is immutable; repetition is usually achieved through recursion rather than loops; pure functions avoid side effects.

Comparison point (up to 1 mark): the imperative style focuses on how to do something (the steps), while the functional style focuses on what to compute (expressions and function composition), which makes functional code easier to parallelise and reason about but sometimes less intuitive for stateful tasks.

Markers reward the change-state-with-loops description of imperative, the immutable-recursion-no-side-effects description of functional, and a valid comparison (how versus what, parallelism).