Continuing woes in reading the ES6 spec language

Brendan Eich brendan at mozilla.com
Fri Sep 13 15:05:24 PDT 2013


Right.

Just to be super-clear, nothing like this is proposed for JS, for the 
reason I gave.

/be

> Sebastian Zartner <mailto:sebastianzartner at gmail.com>
> September 13, 2013 11:52 PM
> FWIW, ColdFusion allows to call functions with named parameters in an 
> arbitrary order.[1] This has one benefit: You can simply skip 
> arguments in the middle instead of having to provide a default value 
> for them the call.
>
> Transferred to JS syntax that would be:
>
> function sayHello(a, b=true, c="people")
> {
>     return b ? a + " " + c : a;
> }
>
> foo(a="Hey", c="there!"); // returns "Hey there!"
>
> (Excuse the poor example, but it should be enough to understand the 
> idea behind it.)
>
> Sebastian
>
> [1] 
> http://stackoverflow.com/questions/1071396/how-to-specify-only-some-optional-arguments-when-calling-function-in-coldfusion
> Oliver Hunt <mailto:oliver at apple.com>
> September 13, 2013 5:39 PM
> On Sep 13, 2013, at 9:18 AM, Brendan Eich<brendan at mozilla.com>  wrote:
>
>>> Oliver Hunt<mailto:oliver at apple.com>
>>> September 13, 2013 6:11 PM
>>> Okay so we were discussing among ourselves, and we thought that a sane "desugaring" for
>>>
>>> function f(x=expr) {
>>> ...
>>> }
>>>
>>> would be
>>>
>>> function f(x) {
>>> if (arguments.length<  1) x=expr;
>>> ...
>>> }
>> ES6 has two things that go against this, already in consensus among those at the meetings (we miss you shiny fruit-company people ;-):
> More of the consensus discussion need to happen on es-discuss, this is the only standards body i'm involved in that seems to require details be hammered out in F2F meetings.  It's one of the things I find disappointing about the ES standard - the avoidance of es-discuss when discussing language features makes it actively difficult for input from the wider dev community.
>
>> * You can have default parameters before parameters without defaults.
> The spec explicitly states that any parameter without a default, but after another parameter that does have a default assignment implicitly has a default property of undefined
>
>> * You can pass undefined to trigger defaulting -- this is important for composition / delegation.
> No, it's a terrible feature :D i'm unaware of any language that supports arbitrary ordering of arguments.
>
> The elegant solution i saw someone mention was
>
> function f({option1, option2, option3} = {option1:default option1, ...}) { … }
>
> That gives you nicely named parameters!  (It was this example that made me start looking at default parameters in the first place)
>
>
>> I think we all agree that new formal parameter syntax gets rid of arguments. Yay!
>
> If only we could kill it everywhere!  My proposal was to simply ban arguments as an identifier entirely
>
>> The real issue that Andreas's proposal addressed was the insanity of body declarations hoisting to be in view of default. But it sounds like we do not have consensus on whether or not that's crazy.
>>> This would produce a consistent and easy to follow semantic for default evaluation, it doesn't introduce any new types of scope, nor does it require any new concepts (temporal dead zones, etc) to be learned by a developer who just wants default parameter values.
>> The hoisting issue still hits your non-consensus actual parameter count (arguments.length) thing, though. When reading the function in source order, one sees a default expression. Mentally moving the defaulting to the body means that hoisted body decls trump outer bindings for names in the expression, indeed. But mentally moving is the objectionable part -- cognitive load, and non-source-order evaluation (more hoisting).
>>
>> Hoisting need not perpetuate itself this way. We can do better, or at least Andreas proposes that we do. I'm sympathetic.
>>
>> Temporal dead zones are indeed weirder but perhaps pay for themselves by catching errors. But is it an error to use an outer name binding in the default expression, given its position in the formal parameter list? I think not.
>
> The problem with temporal dead zones is that they lead to weird behaviour in edge cases, and almost all of them should be syntactically identifiable as errors up front.  The problem is that you can only _almost_ get syntax checked behaviour upfront because eval.
>
>>> We also felt that if you use default or rest parameters we should consider that as a opt out from the magic arguments object, and just poison the arguments identifier entirely (no read, write, or declare)
>> SpiderMonkey's prototype implementation does this, and I asserted above that ES6 specs it. Not so?
>
> The ES6 spec (as far as i can read it) only bans declaration of parameters/vars named "arguments" it doesn't ban reading them.
>
>> /be
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Brendan Eich <mailto:brendan at mozilla.com>
> September 13, 2013 5:18 PM
>> Oliver Hunt <mailto:oliver at apple.com>
>> September 13, 2013 6:11 PM
>> Okay so we were discussing among ourselves, and we thought that a 
>> sane "desugaring" for
>>
>> function f(x=expr) {
>> ...
>> }
>>
>> would be
>>
>> function f(x) {
>> if (arguments.length < 1) x=expr;
>> ...
>> }
>
> ES6 has two things that go against this, already in consensus among 
> those at the meetings (we miss you shiny fruit-company people ;-):
>
> * You can have default parameters before parameters without defaults.
>
> * You can pass undefined to trigger defaulting -- this is important 
> for composition / delegation.
>
> I think we all agree that new formal parameter syntax gets rid of 
> arguments. Yay!
>
> The real issue that Andreas's proposal addressed was the insanity of 
> body declarations hoisting to be in view of default. But it sounds 
> like we do not have consensus on whether or not that's crazy.
>>
>> This would produce a consistent and easy to follow semantic for 
>> default evaluation, it doesn't introduce any new types of scope, nor 
>> does it require any new concepts (temporal dead zones, etc) to be 
>> learned by a developer who just wants default parameter values.
>
> The hoisting issue still hits your non-consensus actual parameter 
> count (arguments.length) thing, though. When reading the function in 
> source order, one sees a default expression. Mentally moving the 
> defaulting to the body means that hoisted body decls trump outer 
> bindings for names in the expression, indeed. But mentally moving is 
> the objectionable part -- cognitive load, and non-source-order 
> evaluation (more hoisting).
>
> Hoisting need not perpetuate itself this way. We can do better, or at 
> least Andreas proposes that we do. I'm sympathetic.
>
> Temporal dead zones are indeed weirder but perhaps pay for themselves 
> by catching errors. But is it an error to use an outer name binding in 
> the default expression, given its position in the formal parameter 
> list? I think not.
>>
>> We also felt that if you use default or rest parameters we should 
>> consider that as a opt out from the magic arguments object, and just 
>> poison the arguments identifier entirely (no read, write, or declare)
>
> SpiderMonkey's prototype implementation does this, and I asserted 
> above that ES6 specs it. Not so?
>
> /be
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Oliver Hunt <mailto:oliver at apple.com>
> September 13, 2013 5:11 PM
> Okay so we were discussing among ourselves, and we thought that a sane 
> "desugaring" for
>
> function f(x=expr) {
> ...
> }
>
> would be
>
> function f(x) {
> if (arguments.length < 1) x=expr;
> ...
> }
>
> This would produce a consistent and easy to follow semantic for 
> default evaluation, it doesn't introduce any new types of scope, nor 
> does it require any new concepts (temporal dead zones, etc) to be 
> learned by a developer who just wants default parameter values.
>
> We also felt that if you use default or rest parameters we should 
> consider that as a opt out from the magic arguments object, and just 
> poison the arguments identifier entirely (no read, write, or declare)
>
> --Oliver
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Andreas Rossberg <mailto:rossberg at google.com>
> September 13, 2013 12:43 PM
>
> Ouch. I'm sorry, I obviously dropped the ball on this. I'll try to
> draft something for next week.
>
> /Andreas
>


More information about the es-discuss mailing list