This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||
|
This article was provided with references by an Unreferenced articles project volunteer on 21 November 2014. If you edit this page, please build on the good work by citing your sources. |
One of the disadvantages listed is "language must be pure". I don't see this as a disadvantage, but just a consequence. In fact, I see it as a major advantage! All strict purely functional languages gave in to the siren call of side effects, non-strict semantics keeps you "honest" and is probably the reason why there even exists any purely functional languages today (and why things like monadic IO was invented - they had to because they couldn't have side effects without them, and laziness ensured that!). The only disadvantage that is truly an undisputed disadvantage is the one about space usage reasoning. I think the whole section should be refactored into a less "evangelical" form (i.e. rather than talking about "disadvantages", talk about "consequences", and perhaps in what circumstances those could be seen as disadvantages).
The article lists Common Lisp as a strict programming language. I am under the impression that Common Lisp functions are strict, but Common Lisp macros are not. Do I understand correctly? —Preceding unsigned comment added by The Storm Surfer ( talk • contribs)
"All hardware architectures 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." Is there a reference for this? In what way are common hardware architectures optimized for strict languages? — Chris Page 15:47, 18 February 2006 (UTC)
I have removed the following sentence from the article: "A non-strict programming language is more expressive than an otherwise equivalent strict language." This claim is patently false; all non-strict programs can be encoded in a strict language using explicit thunks. It may be true that certain programs can be expressed more succinctly in a non-strict language, but that doesn't make it more expressive — just more concise in certain situations (and less concise in others). -- bmills 17:11, 19 February 2006 (UTC)
λ b : (unit -> a) -> (unit -> a) -> a. λ tr : unit -> a. λ fa : unit -> a. λ u : unit. b tr fa
true := λ tr : unit -> a. λ fa : unit -> a. tr ()
false := λ tr : unit -> a. λ fa : unit -> a. fa ()
I was under the impression that Scheme supports/can support some form of lazy evaluation...? -G3, 05:59, 13 December 2006 (UTC)
True, in C, user-defined functions per se are strict, but the built-in operators
&&
,
||
, and
?...:
all
short-circuit, as does
if...else
. Also true, a C++ that overloads these operators
loses the short-circuiting behavior. But a
C preprocessor macro can build a function that includes this short-circuiting behavior. Scheme also has define-syntax
to build a function that short-circuits. --
Damian Yerrick (
talk |
stalk) 15:29, 7 May 2012 (UTC)
Isn't it incorrect to call the game tree of chess finite, when at any point, the players can just keep going back and forth with a single piece? Wouldn't it be more correct to use a cyclic Directed graph for a finite representation?
A strict programming language is a programming language which employs a strict programming paradigm, allowing only strict functions What does that means? It's like a recursive definition — Preceding unsigned comment added by 186.120.227.55 ( talk) 22:09, 17 October 2017 (UTC)
There isn't enough context for this article to be useful, what is it that makes a programming paradigm strict. Is it only necessary that arguments to the function must be evaluated before call, or are there other requirements? Ethanpet113 ( talk) 06:55, 18 November 2018 (UTC)
This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||
|
This article was provided with references by an Unreferenced articles project volunteer on 21 November 2014. If you edit this page, please build on the good work by citing your sources. |
One of the disadvantages listed is "language must be pure". I don't see this as a disadvantage, but just a consequence. In fact, I see it as a major advantage! All strict purely functional languages gave in to the siren call of side effects, non-strict semantics keeps you "honest" and is probably the reason why there even exists any purely functional languages today (and why things like monadic IO was invented - they had to because they couldn't have side effects without them, and laziness ensured that!). The only disadvantage that is truly an undisputed disadvantage is the one about space usage reasoning. I think the whole section should be refactored into a less "evangelical" form (i.e. rather than talking about "disadvantages", talk about "consequences", and perhaps in what circumstances those could be seen as disadvantages).
The article lists Common Lisp as a strict programming language. I am under the impression that Common Lisp functions are strict, but Common Lisp macros are not. Do I understand correctly? —Preceding unsigned comment added by The Storm Surfer ( talk • contribs)
"All hardware architectures 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." Is there a reference for this? In what way are common hardware architectures optimized for strict languages? — Chris Page 15:47, 18 February 2006 (UTC)
I have removed the following sentence from the article: "A non-strict programming language is more expressive than an otherwise equivalent strict language." This claim is patently false; all non-strict programs can be encoded in a strict language using explicit thunks. It may be true that certain programs can be expressed more succinctly in a non-strict language, but that doesn't make it more expressive — just more concise in certain situations (and less concise in others). -- bmills 17:11, 19 February 2006 (UTC)
λ b : (unit -> a) -> (unit -> a) -> a. λ tr : unit -> a. λ fa : unit -> a. λ u : unit. b tr fa
true := λ tr : unit -> a. λ fa : unit -> a. tr ()
false := λ tr : unit -> a. λ fa : unit -> a. fa ()
I was under the impression that Scheme supports/can support some form of lazy evaluation...? -G3, 05:59, 13 December 2006 (UTC)
True, in C, user-defined functions per se are strict, but the built-in operators
&&
,
||
, and
?...:
all
short-circuit, as does
if...else
. Also true, a C++ that overloads these operators
loses the short-circuiting behavior. But a
C preprocessor macro can build a function that includes this short-circuiting behavior. Scheme also has define-syntax
to build a function that short-circuits. --
Damian Yerrick (
talk |
stalk) 15:29, 7 May 2012 (UTC)
Isn't it incorrect to call the game tree of chess finite, when at any point, the players can just keep going back and forth with a single piece? Wouldn't it be more correct to use a cyclic Directed graph for a finite representation?
A strict programming language is a programming language which employs a strict programming paradigm, allowing only strict functions What does that means? It's like a recursive definition — Preceding unsigned comment added by 186.120.227.55 ( talk) 22:09, 17 October 2017 (UTC)
There isn't enough context for this article to be useful, what is it that makes a programming paradigm strict. Is it only necessary that arguments to the function must be evaluated before call, or are there other requirements? Ethanpet113 ( talk) 06:55, 18 November 2018 (UTC)