Jon Zeppieri jaz at bu.edu
Thu Aug 21 08:52:06 PDT 2008

On Thu, Aug 21, 2008 at 11:21 AM, Peter Michaux <petermichaux at gmail.com> wrote:
> On Thu, Aug 21, 2008 at 6:31 AM, Brendan Eich <brendan at mozilla.org> wrote:
>> More helpful would be
>> comments on the utility of let blocks (a.k.a. let statements) and let
>> expressions. Also comparisons to the several let forms in Scheme (Jon
>> Z. posted something a while ago on this topic).
> I was reading the resulting ticket a few days ago.
> http://bugs.ecmascript.org/ticket/375
> I think that the let statement
> let (x = 2, y = x) {
>  print(y);
> }
> should desugar to exactly
> (function(x, y) {
>  print(y);
> })(2, x)
> Also the let expression
> z = let (x = 2, y = x) x + y;
> should desugar to exactly
> z = (function(x, y) x + y)(2, x);
> The reasons for these particular desugarings is this is exactly what
> JavaScript programmers are writing today. It is common to see
> something like the desugared let statement above when looping and
> attaching event handlers to DOM elements, for example.
> I also think that since the name is "let" that the above desugaring
> makes sense as the closest analogy to Scheme's let. It doesn't make
> sense to me to have JavaScript's let be Scheme's let* or letrec. All
> these lets are purely sugar coatings and I'm not opposed to having
> Scheme's let* and letrec added to JavaScript as they introduce even
> sweeter sugar for some situations. I suppose let* would need to be
> renamed.
> Peter

(That's now twice I sent this message from the wrong email address.
Sorry about that.  I'm replying only to the lists now.)

Just to be clear about this: my comments were directed at the claim
that "let is the new var."  It seemed that one of the design goals of
the let *declaration* was that it should be a drop-in replacement for
var, only with block scoping.  That would require (in Scheme terms)
letrec*-like semantics.  Given

 let x = 2, y = x * 2;

... the let-bound x would have to be visible to y's initializer. And given

 let fn = function(n) { if (n === 0) return 1; else return n * fn(n - 1); };

... the 'fn' on the right hand side would refer to the let-bound value
(and not to something in the enclosing scope).

That said, I happen to like plain let semantics.  But if we use those
semantics, then let is certainly not the new var.

Your comments above are about let statements and expressions.  Since
they have no 'var' analogue, the same considerations do not apply.
However, it would be very odd to use letrec* semantics in one case and
let semantics in the others.

So, here is a suggestion that, I am sure, no one but me will like:
drop let declarations and *only* include let statements and
expressions.  Give them let semantics.  Maybe this is only true of me,
but if let statements were in the language, I would never use let
declarations, anyway.  The advantage of the statement and expression
forms is that they make the scope of the let-bound variables explicit.


More information about the Es-discuss mailing list