Editing Functional programming (section)

=== Strict versus non-strict evaluation ===
{{Main|Evaluation strategy}}

Functional languages can be categorized by whether they use ''strict (eager)'' or ''non-strict (lazy)'' evaluation, concepts that refer to how function arguments are processed when an expression is being evaluated. The technical difference is in the [[denotational semantics]] of expressions containing failing or divergent computations. Under strict evaluation, the evaluation of any term containing a failing subterm fails. For example, the expression:

<!-- language? -->
 print length([2+1, 3*2, 1/0, 5-4])

fails under strict evaluation because of the division by zero in the third element of the list. Under lazy evaluation, the length function returns the value 4 (i.e., the number of items in the list), since evaluating it does not attempt to evaluate the terms making up the list. In brief, strict evaluation always fully evaluates function arguments before invoking the function. Lazy evaluation does not evaluate function arguments unless their values are required to evaluate the function call itself.

The usual implementation strategy for lazy evaluation in functional languages is [[graph reduction]].<ref>[http://research.microsoft.com/~simonpj/papers/slpj-book-1987/index.htm The Implementation of Functional Programming Languages]. Simon Peyton Jones, published by Prentice Hall, 1987</ref> Lazy evaluation is used by default in several pure functional languages, including [[Miranda (programming language)|Miranda]], [[Clean (programming language)|Clean]], and [[Haskell]].

{{Harvnb|Hughes|1984}} argues for lazy evaluation as a mechanism for improving program modularity through [[separation of concerns]], by easing independent implementation of producers and consumers of data streams.<ref name="hughesWhyFPMatters">{{cite web |url=http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html |title=Why Functional Programming Matters |author-link=John Hughes (computer scientist) |first=John |last=Hughes |year=1984}}</ref> Launchbury 1993 <!-- a cite arguing more strongly against lazy evaluation would be preferable here, if someone knows of one. --> describes some difficulties that lazy evaluation introduces, particularly in analyzing a program's storage requirements, and proposes an [[operational semantics]] to aid in such analysis.<ref name=launchbury1993>{{cite conference |last=Launchbury |first=John |author-link=John Launchbury |title=A Natural Semantics for Lazy Evaluation |date=March 1993 |conference=Symposium on Principles of Programming Languages |location=Charleston, South Carolina |publisher=[[Association for Computing Machinery|ACM]] |pages=144–154 |doi=10.1145/158511.158618 |doi-access=free}}</ref> Harper 2009 proposes including both strict and lazy evaluation in the same language, using the language's type system to distinguish them.<ref>{{cite book |url=https://www.cs.cmu.edu/~rwh/plbook/book.pdf |archive-url=https://web.archive.org/web/20160407095249/https://www.cs.cmu.edu/~rwh/plbook/book.pdf |archive-date=2016-04-07 |title=Practical Foundations for Programming Languages |author=Robert W. Harper |author-link=Robert Harper (computer scientist) |year=2009}}</ref>