On Aug 23, 2008, at 8:36 PM, Peter Michaux wrote:
> On Sat, Aug 23, 2008 at 7:15 PM, Brendan Eich <[EMAIL PROTECTED]>
> wrote:
>> On Aug 22, 2008, at 4:02 PM, Lex Spoon wrote:
>
>>> So is there anything that is really an issue with the proposed
>>> desugaring?
>>
>> Of course. First, it's unnecessary and confusing to have two ways to
>> write
>>
>> (function (x, y) {...})(a, b)
>
> That statement seems like an anti-sugar statement in general which I
> don't think you are, are you? (I don't think I'm quoting that
> statement out of context.)
First, let's settle the hash over whether any desugaring without
extensions such as return-to-label, reformed lexical scope, tamed
this, banished arguments, etc. etc., trumps adding a new binding
form, to wit: let as block scoped var. That's between Lex and me, and
it's not a philosophical disagreement but a practical one (possibly
factual, since the problems in JS may not be appreciated; talking
about a static language like Scala, or dear old Smalltalk, really
does not help).
Second, you can invent syntax using macros in many languages, but one
hacker's sugar is another's vinegar. ES may get macros, but before
then it does not need every addition to consist of syntax that maps
directly onto the (bad old compatible and broken) core semantics.
Finally, I wrote that "it's unnecessary and confusing to have two
ways to write ..." and you seemed to seize that statement as "anti-
sugar". Which do you disagree with, "unnecessary" or "confusing"?
I call it unnecessary to make let (x = a, y = b) {...} be shorthand
for (function (x, y) {...})(a,b). Count characters: 24 vs. 28. Come
on! It also abuses and preempts 'let', a binding form in many
languages, imposing unwanted costs and visible effects by mandating
desugaring to JS functions (with their |this|, arguments, return/
break/continue isolation, etc. natures). Saying "oh, fix those with
extensions" breaks the desugaring deal.
I call it confusing to have return from within such a let-as-lambda-
call not return to the nearest explicit enclosing function. If the
only benefit is four fewer characters to type, then any burden in
learning or re-learning is not worth it. We do not write-optimize JS
in any event. It's fairly keyword-y already.
> If you do think some sugar is ok, where do you draw the line?
You are ignoring my specific arguments, given before and repeated
above, in order to set up a straw man. I'll knock it down for you
anyway:
There's no question that some sugar is good sugar: avoiding repeated
let {p:p, q:q, r:q} = ... by using the shorthand let {p, q, r} = ...
is a clear win. Redundancy for no good reason (such as avoiding a
grammatical ambiguity) is not justified.
What you seem to call sugar is simply a four-character savings that
would be a personal macro, if we had macros. It would not be part of
the standard. It's not justified by four chars of saved typing, even
if you ignore the substantive problems with mapping let-bindings onto
function parameters.
> How much
> boilerplate needs to be eliminated to make the sugar sweet enough?
No way is 28 instead of 24 chars too much boilerplate.
> If no new semantics are added to JavaScript
Who says no new semantics are being added to JS? Did you miss the
news about generated Name objects? JS1.7 generators also represent
some (obvious) extensions to activation semantics. Even ES3.1 adds
semantics, with things like seal.
> then certainly having
> sugar for writing
>
> (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.
Then write a function definition and call it, if you really need to
return a value early from its body.
Otherwise, use let as implemented in JS1.7 and you can initialize the
bindings in the let-block head. Or use let-as-the-better-var, in a
block.
Again, people aren't using "this pattern" because they like
everything about it but the separation of the actual arguments from
the formal parameters, and the four extra characters of boilerplate.
They're using it because it's all they have. Do not jump to the
conclusion, or try to plant it as an axiom, that every user of this
pattern must have early returns or other such things in the body.
> If the problem JavaScripters are trying to solve with that pattern is
> addressed by adding new semantics then that is a different story.
You need new semantics to avoid all the problems I keep citing with
mapping onto the old semantics.
/be
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
