>> I think it's good to be clear on all these specifics, and people could
>> do with a better recognition of the difference between (non-)strict
>> and (lazy)eager (hint: you can have an eager, non-strict language).
>
> Can you elaborate? That's apparently my blind spot.
A while back, there was a paper on something called (I believe)
optimistic evaluation. The strategy goes like this: when you evaluate
'f x', first you start evaluating 'x'. If that takes too long, or you
encounter an exception, you (re)thunk it, and continue evaluating the
body of f lazy style, in case you don't really need x.
This is arguably eager, since you reduce arguments to functions
immediately if possible. And it has some advantages over lazy
evaluation in common cases. For instance, it avoids foldl building up
a huge nested thunk that would cause a stack overflow. But it isn't
strict, because
const 5 undefined
is still 5.
You can also imagine sparking on every function application, so that
arguments automatically get reduced in parallel, and as soon as
possible. I think that's been determined to not be very effective,
though.
-- Dan