Hi Sean, I think you make a good case for hole preservation. However, holes in
actual and formal parameter lists are not that wanted. You want them for
consistency with holes in array pattern destructuring parameters. That's
unusual, but I grant that if they're useful for destructuring, they cou
On 7 October 2011 17:47, David Herman wrote:
> I don't think we can get away with repurposing _ as a pattern sigil, since
> it's already a valid identifier and used by popular libraries:
>
> http://documentcloud.github.com/underscore/
>
> In my strawman for pattern matching, I used * as the "
I don't think we can get away with repurposing _ as a pattern sigil, since it's
already a valid identifier and used by popular libraries:
http://documentcloud.github.com/underscore/
In my strawman for pattern matching, I used * as the "don't-care" pattern:
http://wiki.ecmascript.org/dok
On 5 October 2011 21:19, Sean Eagan wrote:
> However, I don't see why variable declaration array destructuring
> binding and parameter lists should be different in any way. The only
> current syntactic difference between them is elision:
>
> // allowed
> function f([,,x]){}
> // disallowed
>
Removing these inconsistencies would also allow argument and parameter
lists to be explained in terms of desugaring into array structuring
and destructuring patterns respectively:
function(a, , c = 0, ...d){ //...}
would desugar to:
function(){ var [a, , c = 0, ...d] = _arguments_; // even better
On Mon, Oct 3, 2011 at 4:37 PM, Allen Wirfs-Brock wrote:
> apply supports holes...
>
> f.apply(Array(5));
>
> Look at the specification of apply in section 15.3.4.3 of the ES5/5.1 spec.
> It does a [[Get]] on each element of the argArray to get the value that
> passed in the argument list. [[Get
On Tue, Oct 4, 2011 at 4:09 PM, Sean Eagan wrote:
> On Mon, Oct 3, 2011 at 5:11 PM, Allen Wirfs-Brock
> wrote:
>> as it currently stands, a function is allowed to use both:
>>
>> function f(a,b,c,...rest) {
>> g(...arguments);
>> h(...rest);
>> }
>
> Rest parameters are capable of anything
On Mon, Oct 3, 2011 at 5:11 PM, Allen Wirfs-Brock wrote:
> as it currently stands, a function is allowed to use both:
>
> function f(a,b,c,...rest) {
> g(...arguments);
> h(...rest);
> }
Rest parameters are capable of anything arguments objects are and
more, so what use case would there eve
On Oct 3, 2011, at 1:00 PM, Sean Eagan wrote:
> On Mon, Oct 3, 2011 at 11:35 AM, Allen Wirfs-Brock
> wrote:
>>
>> On Oct 3, 2011, at 8:45 AM, Sean Eagan wrote:
>>
>>> On Mon, Oct 3, 2011 at 10:30 AM, Erik Arvidsson
>>> wrote:
But Function.prototype.apply doesn't preserve holes.
>>>
>>>
On Oct 3, 2011, at 12:42 PM, Sean Eagan wrote:
> On Mon, Oct 3, 2011 at 11:31 AM, Allen Wirfs-Brock
> wrote:
>>
>> On Oct 3, 2011, at 6:49 AM, Sean Eagan wrote:
>>
>>> ...
>
>> In the evolution of the ES language, argument lists predates the existence
>> of destructuring. In the legacy lang
On Mon, Oct 3, 2011 at 11:35 AM, Allen Wirfs-Brock
wrote:
>
> On Oct 3, 2011, at 8:45 AM, Sean Eagan wrote:
>
>> On Mon, Oct 3, 2011 at 10:30 AM, Erik Arvidsson
>> wrote:
>>> But Function.prototype.apply doesn't preserve holes.
>>
>> Function.prototype.apply doesn't preserve holes for the the
>>
On Mon, Oct 3, 2011 at 11:31 AM, Allen Wirfs-Brock
wrote:
>
> On Oct 3, 2011, at 6:49 AM, Sean Eagan wrote:
>
>> So I realized hole preservation is actually relevant in both array
>> structuring and destructuring. Array structuring and destructuring
>> ellipses forms are both specified in the dra
On Oct 3, 2011, at 8:45 AM, Sean Eagan wrote:
> On Mon, Oct 3, 2011 at 10:30 AM, Erik Arvidsson
> wrote:
>> But Function.prototype.apply doesn't preserve holes.
>
> Function.prototype.apply doesn't preserve holes for the the
> `arguments` object, but rest parameters aren't yet standardized, and
On Oct 3, 2011, at 6:49 AM, Sean Eagan wrote:
> So I realized hole preservation is actually relevant in both array
> structuring and destructuring. Array structuring and destructuring
> ellipses forms are both specified in the draft spec to preserve holes.
>
> Argument lists are merely array st
On Mon, Oct 3, 2011 at 10:30 AM, Erik Arvidsson
wrote:
> But Function.prototype.apply doesn't preserve holes.
Function.prototype.apply doesn't preserve holes for the the
`arguments` object, but rest parameters aren't yet standardized, and
are intended to replace the `arguments` object, so they co
But Function.prototype.apply doesn't preserve holes.
On Oct 3, 2011 6:50 AM, "Sean Eagan" wrote:
> So I realized hole preservation is actually relevant in both array
> structuring and destructuring. Array structuring and destructuring
> ellipses forms are both specified in the draft spec to preser
So I guess my deeper question is why we can't just do the following:
* argument lists as array structuring patterns:
ArgumentList :
ElementList
* parameter lists as array destructuring patterns:
ArrayBindingPattern :
[ ArrayBindingElementList ]
FormalParameterList :
ArrayBindingElementLi
So I realized hole preservation is actually relevant in both array
structuring and destructuring. Array structuring and destructuring
ellipses forms are both specified in the draft spec to preserve holes.
Argument lists are merely array structuring patterns, and parameter
lists are merely array d
On Fri, Sep 30, 2011 at 15:27, Allen Wirfs-Brock wrote:
>
> On Sep 30, 2011, at 9:42 AM, Erik Arvidsson wrote:
>
>> On Thu, Sep 29, 2011 at 12:53, Allen Wirfs-Brock
>> wrote:
>>> Also, note that I've currently spec'd ES6 so that 'arguments' can be used as
>>> a rest parameter name. In other wor
On Sep 30, 2011, at 9:42 AM, Erik Arvidsson wrote:
> On Thu, Sep 29, 2011 at 12:53, Allen Wirfs-Brock
> wrote:
>> Also, note that I've currently spec'd ES6 so that 'arguments' can be used as
>> a rest parameter name. In other words
>>function foo(...args) {return args}
>> and
>> function
On Thu, Sep 29, 2011 at 12:53, Allen Wirfs-Brock wrote:
> Also, note that I've currently spec'd ES6 so that 'arguments' can be used as
> a rest parameter name. In other words
> function foo(...args) {return args}
> and
> function foo(...arguments) {return arguments}
> are semantically equiva
On Thu, Sep 29, 2011 at 2:53 PM, Allen Wirfs-Brock
wrote:
> It seems highly desirable that we preserve the existing semantics of arguments
I agree, for backward compatability.
> and that:
> function foo(...args) {
> assert(length.arguments === length.args};
> for (let i in argumen
On Sep 29, 2011, at 12:14 PM, Sean Eagan wrote:
> On Thu, Sep 29, 2011 at 1:31 PM, Allen Wirfs-Brock
> wrote:
>>
>> ...
>
>> I haven't written the spec. for spread in argument lists but clearly
>> interior holes need to be passed as undefined. Trailing holes in a spread
>> in the final argu
On Thu, Sep 29, 2011 at 1:31 PM, Allen Wirfs-Brock
wrote:
>
> On Sep 29, 2011, at 11:07 AM, Sean Eagan wrote:
>
>> Sorry to drag on about array holes, but:
>>
>> Should holes in spread elements (e.g. [...holeyArray]) and arguments
>> (e.g. f(...holeyArray)) reflect as holes in the array they are s
On Sep 29, 2011, at 11:07 AM, Sean Eagan wrote:
> Sorry to drag on about array holes, but:
>
> Should holes in spread elements (e.g. [...holeyArray]) and arguments
> (e.g. f(...holeyArray)) reflect as holes in the array they are spliced
> into to avoid information loss ? The current proposal [1
Sorry to drag on about array holes, but:
Should holes in spread elements (e.g. [...holeyArray]) and arguments
(e.g. f(...holeyArray)) reflect as holes in the array they are spliced
into to avoid information loss ? The current proposal [1] reflects
them as `undefined` values.
Spread arguments wil
26 matches
Mail list logo
