Talk:Strict programming language

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)

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]