Allen's lambda syntax proposal

Mark Miller erights at
Fri Dec 5 11:02:14 PST 2008

On Fri, Dec 5, 2008 at 10:22 AM, Maciej Stachowiak <mjs at> wrote:
> It seems to me the current design prioritizes lambda as a desugaring
> construct or building block for imperative-style control flow, over use as
> an actual first-class function. I assume break and continue inside a lambda
> have similar issues.

Yes. I was initially hopeful that lambdas would be usable in general
as a replacement for function, in much the same way that we are all
hopeful than const and let are usable as a replacement for var.
However, after talking about the hazards Waldemar raised of leaking
completion value, I think your statement above is accurate. It results
in the sugared language having the same two levels as in Smalltalk and
E: The "function" level[1], where a "return" is required in order to
provide a value to one's caller, and a "lambda" level, recommended for
use only for desugaring and control abstraction, where completion
values leak, and where "return" remains bound to the enclosing

In other words, "let" is the new "var", but "lambda" is less than the
new "function" and more than the new block. That's why I argued
against David-Sarah's otherwise very pleasant pattern for writing an
enhanced object literal to express high integrity class-like

[1] ES-Harmony's "function" like Smalltalk's method like E's "to"
    ES-Harmony's "lambda" like Smalltalk's block "[" like E's "method".
    ES-Harmony's "return" like Smalltalk's "^" like E's "return"

Text by me above is hereby placed in the public domain


More information about the Es-discuss mailing list