So, as I understand, choosing default laziness was just experimental design decision in order to answer the >question: "how good lazy language can be". I am practically convinced, that lazy evaluation included in the >_right_ places can be extremely useful. I didn't state the question as "strict vs lazy", my question is different - >"default laziness with optional strict -vs- default strictness with optional lazy". And sorry, but the question >remains open.
at the time, lazyness was also the best-known basis for pure functional i/o (result continuations and monads taking over later), still a hot and tricky topic then. as for defaults, lazy evaluation is normal order strategy + sharing of arguments, strict evaluation corresponds to applicative order strategy, and we know from lambda-calculus that normal order strategy is normalizing (reaches a normal form if one exists) whereas applicative order strategy is not. on this basis, non-strictness is a safe default, with strictness to be inferred or annotated where needed. since strictness is undecidable in general, inference has to be approximate, and a safe default is essential. of course, one can program in mostly strict languages - I started out in one that used applicative order strategy, but had normal order application as well, plus the usual \()->thunking. and as you say, modern versions of default strictness allow you to annotate the function as non-strict, so you don't have to use special application operators everywhere, and lazy-keywords are clearer than \()->thunks. but from my own experience, I had to think a lot more about evaluation order in the default-strict language than I have to in the default-non-strict language, and what is worse, I had to do this thinking up-front, whereas now I can think about the data-dependencies first, and do the thinking about evaluation order later, and only on demand:-) that is also why programs written in default-strict languages often seem to win in performance competitions: if you get it to work at all, you'll also have put in some thoughts on performance/evaluation order already. programs written in default-non-strict languages can be made to "work" without worrying about those details, so it often happens to look as if lazy programs were resource- hungry, and a lot of extra work had to be put in to make them efficient. but I'd put it differently: about the same amount of thought has to be put in to make either kind of program efficient, only that with non-strict default, I get to choose when (and whether) to put in that effort. in other words, default-strict languages are strict in demanding evaluation- order information early, whereas default-non-strict languages give the programmer more leeway. hth, claus