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