Lambda the Ultimate

Lazy evaluation is indeed the star of the show presented, at least as presented in this paper.

But I must say that I am still unsure about lazy eval. It seems to me that supporting lazy constructs (like generators and streams) is a good idea, but that universal lazy evaluation, of the kind found in Haskell, is never going to be the default parameter passing style of major (mainstream) programming languages.

It makes reasoning about space complicated, and many find it confusing.

Thoughts, anyone?

It makes reasoning about space complicated, and many find it confusing.

Thoughts, anyone?

if True  x y = x
if False x y = y
 
(defmacro (let bindings . body)
  `((lambda ,(map car bindings) .,body)
    .,(map cadr bindings)))
 
(defmacro (let* bindings . body)
  (foldr (lambda ((var val) subexp)
           `((lambda (,var) ,subexp) ,val))
         `(begin .,body)
         bindings))

I've especially enjoyed seeing code like this really used to get languages off the ground, more than in lambda-calculus or denotational-semantics tutorials. (That's just me.)

I've just started reading the Haskell `Prelude.hs' from Hugs, which is really enjoyable too. Does anyone have references handy for some other similar code around the place in other styles? (Do e.g. Smalltalk and Forth systems get themselves "into the air" like this?)

These languages offer a set of constructs, and even though they try to present a coherent and well integrated set of features, it is up to us to decide whether these features are also useufl separately, and for what purposes. Morever, language designers like all good artists steal ideas from one another whenever possible (think expcetions, think genericity, think VMs. The list goes on).

Natrually, the fact that lazy constructs such as streams and generators found the way into mainstream languages validates the point Hughes mad in his paper almost twenty years ago.

It is worth asking whether these features can be utilized to their full extent only in functional (or even pure) languages.

True>>ifTrue: trueBlock ifFalse: falseBlock
    ^trueBlock value


False>>ifTrue: trueBlock ifFalse: falseBlock
    ^falseBlock value

Note that "objects" are not only a technique for organizing a program, but they are also a technique for delaying evaluation. The syntax is not always as tidy as in a lazy functional language, but as the program grows ever larger, this is less of an issue, especially with concise languages like Scheme, Smalltalk, or Python, for example.

This I have to see! Can you post some better code for one of the more significant examples, e.g. alpha-beta search? And which language(s) do you have in mind?

This is not quite a definition of if-then-else; if-then-else is not definable in an eager language. I think your Smalltalk definition is analagous to, in ML:

fun ifthenelse true ifbranch elsebranch = ifbranch ()
  | ifthenelse false ifbranch elsebranch = elsebranch ();


val example = ifthenelse true (fn () -> "true") (fn () -> "false")