Why Functional Programming Matters.¶
Hughes, J. (1989). Why Functional Programming Matters. The Computer Journal, 32(2), 98-107.
Cited by¶
3 citations across 3 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Lazy Evaluation
- The eager trade-off is exact and visible — eager evaluation of an infinite list would not terminate at all, so here laziness is not an optimisation but an enabling condition
This sourceArgues that lazy evaluation is an enabling (not merely optimizing) condition — it makes infinite data structures and demand-driven generate-and-select composition tractable.
Supported in partVerified against the publisher's abstract
Hughes's abstract names lazy evaluation as one of two features that push back the conceptual limits on modularisation, supporting the enabling-condition frame but not the infinite-list non-termination fact.
“In this paper we show that two features of functional languages in particular, higher-order functions and lazy evaluation, can contribute greatly to modularity.”
- The eager trade-off is exact and visible — eager evaluation of an infinite list would not terminate at all, so here laziness is not an optimisation but an enabling condition
- Postponement
- The separable decision and commitment is the distinction between constructing an expression and evaluating it: in a lazy language, writing
let xs = map expensive [1..1000000]decides whatxsis without committing to compute any element.This sourceArgues that lazy evaluation defers computation until demand arrives, enabling modular separation of generation from selection.
Supported in partVerified against the publisher's abstract
Hughes's abstract supports only that lazy evaluation aids modularity; it does not carry the construction/evaluation distinction or the `let xs = map ...` example, and the full text was unreachable (HTTP 403).
“In this paper we show that two features of functional languages in particular, higher-order functions and lazy evaluation, can contribute greatly to modularity.”
- The separable decision and commitment is the distinction between constructing an expression and evaluating it: in a lazy language, writing
- Pull Flow
- Software — lazy evaluation, on-demand serverless compute, and pull-based stream subscription versus eager evaluation, scheduled batch jobs, and prefetching.
This sourceArgues that lazy (demand-driven) evaluation produces output only when a consumer demands it — the software analogue of consumer-pull activation, versus eager (producer-paced) evaluation.
Supported in partVerified against the publisher's abstract
The abstract names lazy evaluation as a feature of functional languages that aids modularity; it says nothing about a pull/push contrast, eager evaluation, serverless compute, stream subscription, batch jobs or prefetching.
“In this paper we show that two features of functional languages in particular, higher-order functions and lazy evaluation, can contribute greatly to modularity.”
- Software — lazy evaluation, on-demand serverless compute, and pull-based stream subscription versus eager evaluation, scheduled batch jobs, and prefetching.
Verification¶
Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Read against the text for 3 of 3 citations: 3 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:ac3fc54306f1 · see in the full table