Content deleted Content added
"prior to Java 8" implies Java no longer strict. But it is?! Default evaluation strategy doesn't change that easily, and likely what's mean it that lazy option got added and/or lambda, just while true that's optional to use. https://dzone.com/articles/be-lazy-with-java-8 |
Citation bot (talk | contribs) Misc citation tidying. | Use this bot. Report bugs. | #UCB_CommandLine |
||
| (18 intermediate revisions by 13 users not shown) | |||
Line 1:
{{Short description|Programming language using strict evaluation}}
{{Multiple issues|
{{context|date=November 2018}}
Line 4 ⟶ 5:
}}
A '''strict programming language''' is a [[programming language]]
==
A strict programming language is a [[programming language]] which employs a strict [[programming paradigm]], allowing only [[strict function]]s (functions whose parameters must be evaluated completely before they may be called) to be defined by the user. A non-strict programming language allows the user to define non-strict functions, and hence may allow [[lazy evaluation]].{{Sfn|Scott|2006|p=541}}
Non-strictness has several disadvantages which have prevented widespread adoption:{{Citation needed|date=April 2024}}▼
In most non-strict languages the non-strictness extends to [[algebraic data type|data constructor]]s. This allows conceptually infinite data structures (such as the list of all [[prime number]]s) to be manipulated in the same way as ordinary finite data structures. It also allows for the use of very large but finite data structures such as the complete [[game tree]] of [[chess]].▼
▲Non-strictness has several disadvantages which have prevented widespread adoption:
* Because of the uncertainty regarding if and when expressions will be evaluated, non-strict languages generally must be [[purely functional language|purely functional]] to be useful.
* All [[computer architecture|hardware architecture]]s in common use are optimized for strict languages, so the best compilers for non-strict languages produce slower code than the best compilers for strict languages.
* [[Space complexity]] of non-strict programs is difficult to understand and predict.
* In many strict languages, some advantages of non-strict functions can be obtained through the use of [[Macro (computer science)|macros]] or [[thunk]]s.▼
Strict programming languages are often associated with [[eager evaluation]], and non-strict languages with [[lazy evaluation]], but other [[evaluation strategy|evaluation strategies]] are possible in each case.{{Citation needed|date=April 2024}} The terms "eager programming language" and "lazy programming language" are often used as synonyms for "strict programming language" and "non-strict programming language" respectively.{{Citation needed|date=April 2024}}▼
==Examples==
Nearly all [[programming language]]s in common use today are strict.{{Citation needed|date=April 2024}} Examples include [[C Sharp (programming language)|C#]], [[Java (programming language)|Java]], [[Perl]] (all versions, i.e. through version 5 and version 7), [[Python (programming language)|Python]],<ref>{{cite book |last1=Lott |first1=Steven |title=Functional Python Programming. |date=2015 |publisher=Packt Publishing |___location=Birmingham, UK |isbn=978-1-78439-699-2 |page=35 |quote=Python focuses on strict evaluation}}</ref> [[Ruby (programming language)|Ruby]], [[Common Lisp]], and [[ML (programming language)|ML]]. Some strict programming languages include features that mimic laziness.{{Clarify|date=April 2024|reason=Explain what it means to "mimic laziness"}} [[Raku_(programming_language)|Raku]] (formerly known as Perl 6) has lazy lists,<ref>{{Cite web|title=Raku Programming/Lazy Lists and Feeds - Wikibooks, open books for an open world|url=https://en.wikibooks.org/wiki/Raku_Programming/Lazy_Lists_and_Feeds|access-date=2021-02-09|website=en.wikibooks.org}}</ref> Python has generator functions,<ref>{{cite book |last1=Lott |first1=Steven |title=Functional Python Programming. |date=2015 |publisher=Packt Publishing |___location=Birmingham, UK |isbn=978-1-78439-699-2 |page=35 |quote=a generator function is non-strict. [...] we can leverage generator functions to create lazy evaluation.}}</ref> and [[Julia (programming language)|Julia]] provides a [[Macro (computer science)#Hygienic macros|macro system]] to build non-strict functions,<ref>{{Citation|last=Innes|first=Mike J.|title=MikeInnes/Lazy.jl|date=2021-02-06|url=https://github.com/MikeInnes/Lazy.jl|access-date=2021-02-09}}</ref> as does [[Scheme (programming language)|Scheme]].
Examples for non-strict languages are [[Haskell (programming language)|Haskell]], [[R_(programming_language)|R]], [[Miranda (programming language)|Miranda]], and [[Clean (programming language)|Clean]].{{Sfn|Cluet & Hull|1998|pp=25–26}}
▲Strict programming languages are often associated with [[eager evaluation]], and non-strict languages with [[lazy evaluation]], but other [[evaluation strategy|evaluation strategies]] are possible in each case. The terms "eager programming language" and "lazy programming language" are often used as synonyms for "strict programming language" and "non-strict programming language" respectively.
==Extension==
▲In many strict languages, some advantages of non-strict functions can be obtained through the use of [[Macro (computer science)|macros]] or [[thunk]]s.
{{unreferenced section|date=April 2024}}
▲In most non-strict languages, the non-strictness extends to [[algebraic data type|data constructor]]s. This allows conceptually infinite data structures (such as the list of all [[prime number]]s) to be manipulated in the same way as ordinary finite data structures. It also allows for the use of very large but finite data structures such as the complete [[game tree]] of [[chess]].
==Citations==
Line 37 ⟶ 41:
| others =Published by Denise Penrose
| date =2006
|
| title =Programming Language Pragmatics
| edition ={{Ordinal|2|sup=yes}}
| volume =
| publisher =Morgan Kaufmann
| publication-place =San Francisco
Line 61 ⟶ 65:
| display-editors =2
| date =1998
|
| title =Database Programming Languages
| series =Lecture Notes in Computer Science
| volume =
| publisher =Springer
| publication-place =Berlin; Heidelberg
| |||