On Thu, Aug 21, 2008 at 9:27 AM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> On Aug 21, 2008, at 8:21 AM, Peter Michaux wrote:
>
>> I think that the let statement
>>
>> let (x = 2, y = x) {
>> print(y);
>> }
>>
>> should desugar to exactly
>>
>> (function(x, y) {
>> print(y);
>> })(2, x)
>
> We've been over this. What if you replace print(y) with return y?
Then we can do the following
z = let (x = 2, y = x) {
return y;
}
which is handy in a language that constantly deals with side effects.
There is no Scheme "begin" or Lisp "progn" expression being proposed
which means we will have to write the following pattern
var y;
let (x = 34) {
// side effects lines
document.getElementById('foo').className="n"+x;
// "return" y
y = x+4;
}
where it would be nice to write something like
var y = let (x = 34) begin {
document.getElementById('foo').className="n"+x;
x+4;
}
or as suggested by the desugaring above
var y = let (x = 34) {
document.getElementById('foo').className="n"+x;
return x+4;
}
> I had slides in 2006 talks on ES4 that showed how folks use closures for
> everything, including scoped statements and scoped expressions. That does
> not mean everything should desugar to function applications.
No it does not mean that; however, JavaScript functions have been
shown to be the saving grace of the language and I think it makes
sense to cling to them with all of our programming might. (You may
cite Stockholm Syndrome again and that I have it so don't know it but
there is nothing I can do about that.) Functions are well understood
quantities. Making functions as strong/useful as possible (e.g. adding
tail call elimination) and then adding some sugar to existing common
patterns (i.e. like having some built-in macros to ease boilerplate
pain) makes a lot of sense to me. High quality functions and sugar
built on them is a safe bet/insurance policy.
> Besides the return issue, there are break and continue to consider, and the
> arguments object.
Break and continue would be syntax errors.
I'd expect the arguments object inside a let block to refer to to the
let block's arguments. The arguments object will be less of an issue
with rest arguments.
"this" has been mentioned in other posts but it is "fixed" with the
proposal that inner functions have their outer function's this value.
> Desugaring may seem all the rage from the Harmony classes as sugar
> discussion, but it is not the only or best way, and it bites back. We do not
> want to overspecify so that the abstraction leaks and you can see the
> mutable, argument-ful, expensive functions under the hood.
>
>
>> 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.
>
> So what?
Maybe "so what?" but it makes it easy to explain what let is: simple
sugar for an existing pattern.
> Programmers do what they must in a language that has not evolved in
> nine years.
True but by the same token as some of your arguments, that doesn't
make current practices wrong either.
> I cited Stockholm Syndrome the other day. It's a problem in JS-land. Users
> happy with closures for everything should go on using them. These are not
> the self-appointed victims I mean. But to say that let and block scope (and
> possibly other binding facilities not desugarable to ES1-3.x) must be
> spelled out exactly this way is bogus.
I'm not suggesting the "must be" but that it seems sensible that they are.
> Besides the leaks and inefficiencies,
> it makes a virtue of necessity, or of a vice.
Peter
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
