Earlier quoted context omitted.
> And that makes me grumpy sometimes. If you will excuse a moment of cheekiness... Could be that you have cause and effect backwards here: because you are grumpy you are dismissing 99% of other language developers' work as rubbish. Could be that it's less than 99% and you are overlooking some great ideas.
That's not cheeky, it's a perfectly fair question. Yes, that is certainly possible. And there have been a few cool new ideas that have come along that are not easily subsumed by CL, like Haskell's type system. It's easy to implement Hindley-Milner, but actually using that information to inform the compiler, plus adding laziness as a core language feature, is much harder. But I think the jury is still very much out on…
C:\Users\kaz>txr
This is the TXR Lisp interactive listener of TXR 162.
Use the :quit command or type Ctrl-D on empty line to exit.
1> (defstruct integers ()
val next
(:postinit (me)
(set me.next (lnew integers val (succ me.val))))
(:method print (me stream pretty-p)
(format stream "#" me.val)))
#
2> (lnew integers val 0)
#
3> *2.next
#
4> *2.next.next
#
5> *2.next.next.next
#
Why would I want implicit laziness everywhere? The best of all worlds is to have expressions reduced to their values eagerly before a function call takes place.When I don't want an expression evaluated in (what looks like) a function call, I can, firstly, make that a macro.
If I really want lazy semantics, I can have a decent vocabulary of lazy constructs that fit into the eager language. For instance for making objects lazily I have lnew, distinct from new.
Implicit laziness everywhere is academically stupid. You're drowning the execution of the code in an ocean of thunks and closures.
The pragmatic approach is best of making a compromise between making everything explicit and visible, yet keeping it syntactically tidy and convenient.