Talk:Strict programming language

Disadvantages

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).

Common Lisp

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)

As far as I can tell, macros are not directly related to strictness. Strictness relates to evaluation strategy, but macros are without evaluation strategy, as they are meta-evaluated. In effect, a macro can be used to change the evaluation strategy, so you can achieve macros that behave non-strictly. —Preceding unsigned comment added by 82.181.66.63 (talk • contribs)

I feel that this is worth a mention in the article. For example, Structure and Interpretation of Computer Programs in section 3.5 uses delayed evaluation via two macros (delay and force) in Scheme to implement data structures such as infinite lists (streams). Since this is actually practical and used in the Lisp family, this matter should be clarified in the article. 132.236.75.84 (talk) 15:28, 30 November 2009 (UTC)

Can't streams be implemented without macros in Scheme/Racket? — Preceding unsigned comment added by 77.101.47.254 (talk) 12:10, 7 November 2013 (UTC)

Hardware optimized for strict languages?

"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)

Hmm, I've heard it in the form that all machine architectures would be optimized for C, which of course is a strict language. It could be easier to find references for what common hardware is missing from the lazy language point of view. --TuukkaH 16:36, 18 February 2006 (UTC)

So, here's the thing — there's no such think as a hardware thunk (at this point), so one could claim that hardware is optimized for languages without thunks. Not that it really matters, though; strict programming language, lazy evaluation, and eager evaluation all seem to have been created by people advocating a particular POV, and they've become essentially a forum for debating the two (even though lazy evaluation and eager evaluation are really just overgeneralized notions about families of evaluation strategies). At some point I intend to clean them up a bit. --bmills 17:04, 19 February 2006 (UTC)

It seems to me that this is soley an implementation issue. Who says lazy languages must be implemented in a way which is slow for current hardware? Seems unnecessary to mention anything like that as a fact. Indeed, non-strict semantics can be a significant optimization (thus producing much faster code) due to the avoidance of unnecessary work. Dogmatic generalisations about performance shouldn't be in here.

Expressiveness

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)

Non-strictness is important for expression, but as we define a non-strict language as one where the programmer can define non-strict functions, a strict language can have non-strictness, and most do. It's hard to imagine an imperative language without non-strict parts, but what about a purely functional language? Without a non-strict if/cond function, you're in trouble. In a strict language, you can't define higher-level conditional statements. Same goes for thunks, you need a way to implement them in the first place. I think it would be fair to explain how in theory non-strictness makes a lot of sense. --TuukkaH 17:33, 19 February 2006 (UTC)

It's true that conditional expressions generally have some non-strictness in the evaluation of conditional branches. However, thunks can be implemented using functions, and a "conditional function" could be a function that takes a boolean-thunk and two (unconditional) branch-thunks, and returns an unconditional thunk that, when executed, calls the boolean thunk and the appropriate branch-thunk.

Consider the following example in typed lambda calculus, which takes a boolean and two functional thunks and returns another thunk:

λ b : (unit -> a) -> (unit -> a) -> a. λ tr : unit -> a. λ fa : unit -> a. λ u : unit. b tr fa

In this case, b could be a suspended Church encoding of "true" or "false":

true := λ tr : unit -> a. λ fa : unit -> a. tr ()
false := λ tr : unit -> a. λ fa : unit -> a. fa ()

So all you really need are functions and unit; non-strictness is just a matter of convenience if you don't want to deal with explicitly invoking your thunks. I won't claim it's not convenient, because it is; but it's not really a matter of expressiveness. --bmills 19:26, 19 February 2006 (UTC)

So expressiveness is the same thing as power of the computational model? I don't remember a good definition of expressiveness, but I'd say it's more about being as far from the computational models as possible =) Basicly, if you need to start writing thunks to use a new conditional statement, you don't define a new conditional statement. Plus, with functions above you meant first-class functions, which aren't available in every language. --TuukkaH 20:12, 19 February 2006 (UTC)

Formal "expressiveness" of a language generally refers to which subset of computable functions it can represent. Since strict and non-strict evaluation can each represent the same functions, they have equivalent expressive power; in a strict language, you can simulate non-strictness using thunks, and in a non-strict language, you can simulate strictness using monads. I believe they're actually logical duals, but I don't know the proper citation for that.

At any rate, I'm definitely not saying that non-strictness isn't useful; I'm just saying that it doesn't give you any additional expressiveness. And I did use first-class functions in my example, because you asked about pure functional languages; however, you could equivalently formulate it in, say, C, using closure-passing style. --bmills 03:43, 20 February 2006 (UTC)

I think I wrote the disputed sentence, and I think I meant it in the following precise sense: when you switch from strict to non-strict semantics, all non-divergent programs continue to work with the same meaning as before, and additionally some formerly divergent programs acquire a meaning, i.e. the set of valid programs is a strict superset of what it was before. I don't think "more expressive" is a very good way of describing this, but it's an interesting property that ought to be mentioned somewhere. (Though it no longer holds if you add exceptions to the language, so maybe it doesn't have much practical relevance.) -- BenRG 18:01, 20 February 2006 (UTC)

It is true that non-strict evaluation has the same partial correctness behavior as strict evaluation; in practice it doesn't really make that much difference because function arguments rarely diverge, but it's certainly an interesting aspect to note. Be careful when talking about "meaning", though — some would say that divergence is a meaning as well, in which case non-strict evaluation does change the meaning of some programs. Anyway, I'm not opposed to including that fact — it just needs to be phrased very carefully to avoid hitting any of the (absurdly many) loaded words in formal PL. --bmills 18:57, 20 February 2006 (UTC)

Scheme

I was under the impression that Scheme supports/can support some form of lazy evaluation...? -G3, 05:59, 13 December 2006 (UTC)

C is not strict

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)

Regarding Chess's game tree

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?

Difficult to understand

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)

If I'm not mistaken you mean it is a circular definition. Yes there doesn't seem to be a strict definition of what strict means hereEthanpet113 (talk) 06:50, 18 November 2018 (UTC)

No Context

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)