On Aug 23, 2008, at 10:23 PM, Mark S. Miller wrote:
> On Sat, Aug 23, 2008 at 8:36 PM, Peter Michaux
> <[EMAIL PROTECTED]> wrote:
>> (function (x, y) {...})(a, b)
>>
>> would be quite welcome. It is clear people like this pattern and
>> it is
>> confusing when the formals and actuals are more than a couple and
>> more
>> than a couple lines apart.
>
> As Lars pointed out, using ES-Harmony's optional parameters with
> defaults, you can keep the actuals and formals together by writing
>
> (function (x=a, y=b){...})()
>
Good point, although I say it's no fair to talk desugaring but then
special-plead extensions into the mix. Optional parameters are not
just syntax, especially in their evaluation and scope rules.
> Given this, I don't see any need for let blocks or let expressions
> that justifies their added complexity.
They may indeed not be justified on complexity grounds, but I'd like
to argue against your reason:
> Especially since, as we've
> established, they can't be added as sugar that desugars to anything
> like the above code.
The above code has issues in the ... you didn't show. |this|,
arguments aliasing, the arguments name shadowing an outer arguments
that would otherwise be visible, e.g., in a JS.1.7 let block, and
probably other compatibility burdens I'm forgetting atm, all make it
undesirable to map a binding form with explicitly delimited scope and
let-not-letrec rules for initialization (JS1.7's let block or let
expression) onto a lambda-call.
So let blocks and expressions indeed can't desugar -- that could be
the end of it. But that argument does not prevail in all cases,
particularly in the case of let declarations (let as the new var),
which I believe you support.
My counter-argument is this: If the existing semantics have their own
complexity problems, even though we are stuck with them for
compatibility, we could make the language better overall, and some
day hope to move programmers off bad old forms, by adding some
carefully designed better forms. Desugaring is not the only good to
consider. Reforming the core semantics while keeping compatibility
may require new runtime semantics.
I agree with you that conserving runtime semantics when adding syntax
is a good discipline and an appropriate bias. But the lexical scope
breaks, the extra gewgaws such as |this| and arguments that afflict
JS functions should not be ignored.
/be
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
