Popular conceit about learning programming languages

[Michael Hudson]

Lulu of the Lotus-Eaters <mertz at gnosis.cx> writes:

> |Lulu of the Lotus-Eaters <mertz at gnosis.cx> writes:
> |> The term 'strict' has another antonym that is probably more useful:
> |> 'lazy'.
> 
> Michael Hudson <mwh at python.net> wrote previously:
> |But I think in technical pointy-eared CS speak, 'lazy' has a technical
> |meaning that differs slightly from what Haskell does.
> |I used to know the difference, but I've forgotten; something like lazy
> |means you evaluate a subexpression *each* time its value is used?
> |Haskell doesn't do that.
> 
> There might well be a difference between "non-strict" and "lazy" that I
> am unaware of.  I know these things only casually, not in a pointy-eared
> CS way.
> 
> But for a pure functional language to evaluate a subexpression each
> time its value is used is just plain foolish.  Since you know--by
> definition once state is removed--that a subexpression will always
> evaluate to the same thing, deciding never to cache that value is
> pointless.  I kinda suspect that whatever "lazy" really means precisely,
> it isn't "burns cycles needlessly" :-).

Yeah, I kinda thought that.

I went and looked it up in the foldoc.  Turns out a function `func' is
"non strict" if 

    func bottom

is something other than bottom.  To quote the foldoc, "lazy
evaluation" is a _reduction strategy_ combinining normal order
evaluation with updating.

So it's a bit absurd to describe a language as non-strict, except to
mean that it is possible to write non strict functions in the
language.  Lazy evaluation is a way of arranging that to be possible.
I don't know if Haskell98 mandates lazy evaluation.

Cheers,
M.

-- 
  The PROPER way to handle HTML postings is to cancel the article,
  then hire a hitman to kill the poster, his wife and kids, and fuck
  his dog and smash his computer into little bits. Anything more is
  just extremism.                                 -- Paul Tomblin, asr