On Thu, Aug 21, 2008 at 9:27 AM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> Besides the return issue, there are break and continue to consider,
> and the arguments object.
And "this". At least the "this" issue can be handled by a moderately
more complex desugaring without renaming: If the original mentions
"this" freely, then the desugared closure would be invoked with
".call(this, ...)" rather than "(...)". But the other issues cannot be
so pleasantly handled. Closures in Scheme and Smalltalk do not have
any of these problems. It is a shame that closures in JavaScript are
not as well behaved, but that is the situation we have to live with.
> 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.
I think we need to take these on a case by case basis. When a
desugaring into functions doesn't leak or bite back, then we should
prefer to specify things this way rather than introduce new primitive
semantics.
>> 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? Programmers do what they must in a language that has not
> evolved in nine years.
But there should not have been anything wrong with the semantics of
z = (function(x, y) x + y)(2, x);
to define the semantics of z = let (x = 2, y = x) x + y;
Since we're talking about expressions here, return/break/continue are
not problems. "this" is a fixable problem as above. "arguments" is
likely to be removed in ES-Harmony strict mode. The function-value
itself never becomes reachable by other means, so its identity and
mutability are not observable. So defining the semantics of let
expressions by this desugaring looks not-very-leaky.
Btw, Lars pointed out that since ES-Harmony has optional parameters
with defaults, we could avoid textually separating the args from the
parameters. Combining suggestions:
z = (function(x=2, y=x) x+y)();
// since the original body didn't mention "this"
or
z = (function(x=2, y=x) foo(this)+x+y).call(this);
// if the original body were "foo(this)+x+y"
It has been suggested (perhaps by me -- I really don't remember) that
optional and rest parameters should preclude use of "arguments" even
in non-strict mode. If that were the case, then the only remaining
leakiness of the above expansion is that it would prohibit use of
"arguments" in the original let-body expression.
Btw, none of my remarks above should be taken as an endorsement of
adding either the let statement or the let expression to the language.
I am in favor of let-as-the-new-var with letrec semantics. As for
these others, I am skeptical as to whether they are worth their weight
-- even as pure sugar.
> 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 agree that "must" is too strong, but "bogus" seems too harsh. When
definition by desugaring is adequate, it should be preferred. When it
isn't adequate, we should examine whether there are other ways of
repairing the situation without expanding the desugared semantics of
the language.
> Besides the leaks and inefficiencies, it makes a virtue of
> necessity, or of a vice.
JavaScript's semantics are already too large and complicated. Further
expansion of these semantics should be considered a vice, even it if
will sometimes be a necessity. I don't think we're really disagreeing
here about substantive points, but value-laden words also convey an
emphasis. I come at these issues with a different emphasis.
--
Cheers,
--MarkM
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
