Alan,

Hi,
I think a big advantage is that programs can be written without regard for whether or not a value will in the long run actually be evaluated.
For me one of the best examples of this is that of logging within a compiler.

[example goes here]

Now if this is a strict language we have to go and modify all the intermediate functions to first of all take in a boolean and then use that to decide whether or not to produce any logging information. With a lazy language though, we don't need to do that, we're already done, no logging information will be produced if 'logOrNot' is false, because it will never be forced to evaluate the thunk.

Yes, I agree, lazy evaluation is important, but unfortunately you didn't convince me that it should be on *by default*. In strict languages we usually some facility like macros, and with them we can do everything like that (and with better performance). Or, we could make the logging function (called by functions inside convertToIntermediate, convertToAssembly etc) as lazy (mark them as lazy or change them to lazy form). For example, Scala again:

/* Lazily compute the logger. The computation will not start running until the value of 'logger' is actually requested. */ var logger = lazy({ Logging.getLogger() }) /* This will start the computation */ logger.debug("medved") /* No delay to compute the logger again, as it has already been calculated */ logger.debug("preved")

According to one guy's analogy: the Real World is strict - in order to drink tea, you have to put the kettle on the fire, wait until water boils, brew tea and then drink. Not the kettle is put on the fire, water boils and the tea is brewed when you take the empty cup to start drinking. :-)

Yes true, but you don't just boil up the kettle and brew the tea unless you have first asked if anyone actually wants tea.

Hmm, the analogy is very flexible, and yours argument is also reasonable.
(Oops, yes - kettle should be put on the fire, not cattle :-D)

Best regards,
Nick