three small proposals: the bikeshed cometh!

Mark S. Miller erights at
Thu Apr 29 16:18:21 PDT 2010

On Thu, Apr 29, 2010 at 10:03 AM, Brendan Eich <brendan at> wrote:


> // 2.) Shorthand for "function", aka the "not lambda"
> [...]
>  // equivalent:
>  function(){ return 10; }
>  #(){ return 10; }
>  #{ return 10; } // no args, optionally elide ()
> This does several things at once, and we have discussed one of them:
> turning the completion value of the body into the return value.
> The objection to this, voiced clearly by Waldemar, is the unintended
> completion value in tail position leaking out as a return value. This is
> hard to see and test for, and it requires ugly void operator usage, or a
> dummy final value, to control.
> Dave Herman has recently proposed
>, which
> include an explicit "completion value here" prefix: => 10; in tail position
> would result in 10, and without => the result would be the undefined value.
> * equivalent semantics to the function(){} syntax
> No, not equivalent because tail position completion values are not return
> values with functions. Again semantics matter, not just syntax.

First of all, +1 for Dave's let expression syntax. The ASI issues I just
raised are details. Whatever answers we arrive at for those, I'm still +1 on
let expressions.

Second, +1 on "#" as a short way to define closures, whether they are simply
replacing the "function" keyword or introducing a genuine lambda.

Third, given the first two, +1 on "#" reviving lambda, with Dave's same "=>"
replacing the notion of completion value within the lambda body.

I know that in the past I have advocated let expressions while agreeing to
drop lambda. However, now that I've had time to sleep on introducing let
expressions into the language, I think the marginal psychological complexity
of introducing lambda along with let is not so great after all. And it
avoids a different source of confusion. For example, without lambda, when
people improve iteration code like

    for (var i = 0; i < arr.length; i++) {
        // ...
        if (pred(arr[i])) { return arr[i]; }
        // ...

to use the new array generics, they will often first write

    arr.forEach(function(el) {
        // ...
        if (pred(el)) { return el; }
        // ...

which won't work at all. By contrast, if "#" means lambda,

    arr.forEach(#(ev) {
        // ...
        if (pred(el)) { return el; }
        // ...

will work just fine. The array generics really are our first
non-special-form control abstractions. Control abstractions without a
TCP-respecting lambda will simply be confusing. Control abstractions without
a short function call syntax (whether meaning lambda or function) are simply
too verbose.

Even if lambda remains rejected, I'd still prefer "#" for "function", rather
than to leave the current verbosity unrepaired.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list