return when desugaring to closures

Brendan Eich brendan at mozilla.org
Sun Aug 24 00:17:14 PDT 2008


On Aug 23, 2008, at 8:36 PM, Peter Michaux wrote:

> On Sat, Aug 23, 2008 at 7:15 PM, Brendan Eich <brendan at mozilla.org>  
> 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


More information about the Es-discuss mailing list