Negative indices for arrays

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Negative indices for arrays

Dmitry Soshnikov
Hello,

How likely (based on backward compats) that Harmony will support
Pythonic negative indices for arrays? Ruby supports them too. There was
previous indirect mention, were Brendan agreed that Harmony needs such a
semantics for arrays, however, that discussion wasn't formed to
something concrete.

Recently, there was the same discussion in CoffeeScript's tracker --
https://github.com/jashkenas/coffee-script/issues#issue/827 . Since
Coffee uses JavaScript as its lower level, there were proposals to
provide an alternative syntax for this (e.g. a[* - 1], where * means
a.length, allowing this feature to be generic), though, I'm not sure
this exact syntax is needed for ES. However, I mentioned there, that if
Harmony itself will support this feature in Python's/Ruby's semantics,
then Coffee won't need an alternative thing.

Currently, this feature may be easily implemented using proxies:
https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/array-negative-indices.js 
(example),
https://github.com/DmitrySoshnikov/es-laboratory/blob/master/src/array-negative-indices.js 
(implementation), however possibly it's good to have this semantics for
objects with [[Class]] "Array" as native. I think it's acceptable, since
we already have such alternative semantics for String objects.

Toughs?

Dmitry.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Dmitry Soshnikov
On 11.11.2010 13:24, Dmitry A. Soshnikov wrote:
>
>  There was previous indirect mention, were Brendan agreed that Harmony
> needs such a semantics for arrays

Sorry, forgot the link
https://mail.mozilla.org/pipermail/es-discuss/2010-May/011115.html

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Dmitry Soshnikov
In reply to this post by Dmitry Soshnikov
On 11.11.2010 13:24, Dmitry A. Soshnikov wrote:
>
> Toughs?
>

Funny typo :D Sorry.

Thoughts?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Dmitry Soshnikov
In reply to this post by Dmitry Soshnikov
Actually, I'm still not sure myself whether I want this semantics in JS for arrays. I remember one case (some simple math task) when I was needed a[-1] and was glad that JS supports it -- I used `for (var i = -2; i < 10; i++) a[i]`, and it was very elegant decision at that moment.

There is also one lack (?) with decreasing counter loop (brought in discussion on Twitter), e.g.:

var a = [1, 2, 3], i = a.length;

while (v = a[--i]) {
  print(i, v)
}

that brings: 2,3  1,2  0,1  -1,3  -2,2  -3,1

i.e. double enumeration with this semantics. But formally, it's not a bug, but a feature -- both Python and Ruby have the same semantics in such a `while` case.

Another reason I'm still no sure about a[-1] is that JS (in contrast with the same Python and Ruby) has no stratification of normal properties -- via dot notation, and subscription properties -- via square bracket notation. I mentioned this in previous mentioned thread. And from this viewpoint, probably it's not good that o[-1] means exactly "-1" and a[-1] means a[`last`]. Don't know.

Want both -- and (probably sometimes needed) "-1", and sugar for [`last`].

Though, repeat, since ES5 brought special semantics for subscription of strings, i.e. "abc"[0] is "a", maybe it worth to make another sugar for arrays too? Btw, if yes, it will touch strings too.

Dmitry.

On 11.11.2010 13:24, Dmitry A. Soshnikov wrote:
Hello,

How likely (based on backward compats) that Harmony will support Pythonic negative indices for arrays? Ruby supports them too. There was previous indirect mention, were Brendan agreed that Harmony needs such a semantics for arrays, however, that discussion wasn't formed to something concrete.

Recently, there was the same discussion in CoffeeScript's tracker -- https://github.com/jashkenas/coffee-script/issues#issue/827 . Since Coffee uses JavaScript as its lower level, there were proposals to provide an alternative syntax for this (e.g. a[* - 1], where * means a.length, allowing this feature to be generic), though, I'm not sure this exact syntax is needed for ES. However, I mentioned there, that if Harmony itself will support this feature in Python's/Ruby's semantics, then Coffee won't need an alternative thing.

Currently, this feature may be easily implemented using proxies: https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/array-negative-indices.js (example), https://github.com/DmitrySoshnikov/es-laboratory/blob/master/src/array-negative-indices.js (implementation), however possibly it's good to have this semantics for objects with [[Class]] "Array" as native. I think it's acceptable, since we already have such alternative semantics for String objects.

Toughs?

Dmitry.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Dmitry Soshnikov
OTOH, negative indices, are even not array indices. I.e.

var a = [1,2];
a[-1] = 0;
print(a); // 1,2
print(a.length); // 2

From this viewpoint -- for what are they? Seems again, `-n` notations for arrays and strings is useful as a "from the end"-sugar. So now I may propose it.

On 11.11.2010 21:26, Dmitry A. Soshnikov wrote:
Actually, I'm still not sure myself whether I want this semantics in JS for arrays. I remember one case (some simple math task) when I was needed a[-1] and was glad that JS supports it -- I used `for (var i = -2; i < 10; i++) a[i]`, and it was very elegant decision at that moment.

There is also one lack (?) with decreasing counter loop (brought in discussion on Twitter), e.g.:

var a = [1, 2, 3], i = a.length;

while (v = a[--i]) {
  print(i, v)
}

that brings: 2,3  1,2  0,1  -1,3  -2,2  -3,1

i.e. double enumeration with this semantics. But formally, it's not a bug, but a feature -- both Python and Ruby have the same semantics in such a `while` case.

Another reason I'm still no sure about a[-1] is that JS (in contrast with the same Python and Ruby) has no stratification of normal properties -- via dot notation, and subscription properties -- via square bracket notation. I mentioned this in previous mentioned thread. And from this viewpoint, probably it's not good that o[-1] means exactly "-1" and a[-1] means a[`last`]. Don't know.

Want both -- and (probably sometimes needed) "-1", and sugar for [`last`].

Though, repeat, since ES5 brought special semantics for subscription of strings, i.e. "abc"[0] is "a", maybe it worth to make another sugar for arrays too? Btw, if yes, it will touch strings too.

Dmitry.

On 11.11.2010 13:24, Dmitry A. Soshnikov wrote:
Hello,

How likely (based on backward compats) that Harmony will support Pythonic negative indices for arrays? Ruby supports them too. There was previous indirect mention, were Brendan agreed that Harmony needs such a semantics for arrays, however, that discussion wasn't formed to something concrete.

Recently, there was the same discussion in CoffeeScript's tracker -- https://github.com/jashkenas/coffee-script/issues#issue/827 . Since Coffee uses JavaScript as its lower level, there were proposals to provide an alternative syntax for this (e.g. a[* - 1], where * means a.length, allowing this feature to be generic), though, I'm not sure this exact syntax is needed for ES. However, I mentioned there, that if Harmony itself will support this feature in Python's/Ruby's semantics, then Coffee won't need an alternative thing.

Currently, this feature may be easily implemented using proxies: https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/array-negative-indices.js (example), https://github.com/DmitrySoshnikov/es-laboratory/blob/master/src/array-negative-indices.js (implementation), however possibly it's good to have this semantics for objects with [[Class]] "Array" as native. I think it's acceptable, since we already have such alternative semantics for String objects.

Toughs?

Dmitry.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Oliver Hunt-2

On Nov 11, 2010, at 11:30 AM, Dmitry A. Soshnikov wrote:

OTOH, negative indices, are even not array indices. I.e.

var a = [1,2];
a[-1] = 0;
print(a); // 1,2
print(a.length); // 2

From this viewpoint -- for what are they? Seems again, `-n` notations for arrays and strings is useful as a "from the end"-sugar. So now I may propose it.

They're property names, what you're suggesting would be a fairly dramatic change in behaviour and I would be concerned about it causing site breakages.

I can easily imagine code that did:
var someArray = ..;
var i = someArray.length;
while(v = someArray[--i]) { .. do something... }

Which would now be wrong.

Likewise bugs that lead to code doing a[-1]=foo; would change from being "safe" to modifying the content of the actual array values.

I'm sure I've had this discussion before, the fundamental problem is that ES does not really distinguish between dot and bracket property access, whereas afaik python does (i don't know about ruby).

--Oliver


On 11.11.2010 21:26, Dmitry A. Soshnikov wrote:
Actually, I'm still not sure myself whether I want this semantics in JS for arrays. I remember one case (some simple math task) when I was needed a[-1] and was glad that JS supports it -- I used `for (var i = -2; i < 10; i++) a[i]`, and it was very elegant decision at that moment.

There is also one lack (?) with decreasing counter loop (brought in discussion on Twitter), e.g.:

var a = [1, 2, 3], i = a.length;

while (v = a[--i]) {
  print(i, v)
}

that brings: 2,3  1,2  0,1  -1,3  -2,2  -3,1

i.e. double enumeration with this semantics. But formally, it's not a bug, but a feature -- both Python and Ruby have the same semantics in such a `while` case.

Another reason I'm still no sure about a[-1] is that JS (in contrast with the same Python and Ruby) has no stratification of normal properties -- via dot notation, and subscription properties -- via square bracket notation. I mentioned this in previous mentioned thread. And from this viewpoint, probably it's not good that o[-1] means exactly "-1" and a[-1] means a[`last`]. Don't know.

Want both -- and (probably sometimes needed) "-1", and sugar for [`last`].

Though, repeat, since ES5 brought special semantics for subscription of strings, i.e. "abc"[0] is "a", maybe it worth to make another sugar for arrays too? Btw, if yes, it will touch strings too.

Dmitry.

On 11.11.2010 13:24, Dmitry A. Soshnikov wrote:
Hello,

How likely (based on backward compats) that Harmony will support Pythonic negative indices for arrays? Ruby supports them too. There was previous indirect mention, were Brendan agreed that Harmony needs such a semantics for arrays, however, that discussion wasn't formed to something concrete.

Recently, there was the same discussion in CoffeeScript's tracker -- https://github.com/jashkenas/coffee-script/issues#issue/827 . Since Coffee uses JavaScript as its lower level, there were proposals to provide an alternative syntax for this (e.g. a[* - 1], where * means a.length, allowing this feature to be generic), though, I'm not sure this exact syntax is needed for ES. However, I mentioned there, that if Harmony itself will support this feature in Python's/Ruby's semantics, then Coffee won't need an alternative thing.

Currently, this feature may be easily implemented using proxies: https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/array-negative-indices.js (example), https://github.com/DmitrySoshnikov/es-laboratory/blob/master/src/array-negative-indices.js (implementation), however possibly it's good to have this semantics for objects with [[Class]] "Array" as native. I think it's acceptable, since we already have such alternative semantics for String objects.

Toughs?

Dmitry.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Ash Berlin-5
In reply to this post by Dmitry Soshnikov
On 11 Nov 2010, at 19:30, Dmitry A. Soshnikov wrote:
> OTOH, negative indices, are even not array indices. I.e.
>
> var a = [1,2];
> a[-1] = 0;
> print(a); // 1,2
> print(a.length); // 2
>
> From this viewpoint -- for what are they? Seems again, `-n` notations for arrays and strings is useful as a "from the end"-sugar. So now I may propose it.


Yes please, both perl and ruby have it and I often find myself instinctively typing it in JS.

-ash
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Dmitry Soshnikov
On 11.11.2010 22:39, Ash Berlin wrote:

> On 11 Nov 2010, at 19:30, Dmitry A. Soshnikov wrote:
>> OTOH, negative indices, are even not array indices. I.e.
>>
>> var a = [1,2];
>> a[-1] = 0;
>> print(a); // 1,2
>> print(a.length); // 2
>>
>>  From this viewpoint -- for what are they? Seems again, `-n` notations for arrays and strings is useful as a "from the end"-sugar. So now I may propose it.
>
> Yes please, both perl and ruby have it and I often find myself instinctively typing it in JS.
>

And Python too (from langs I know). Other probably also.

> -ash
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Dmitry Soshnikov
In reply to this post by Oliver Hunt-2
On 11.11.2010 22:39, Oliver Hunt wrote:

On Nov 11, 2010, at 11:30 AM, Dmitry A. Soshnikov wrote:

OTOH, negative indices, are even not array indices. I.e.

var a = [1,2];
a[-1] = 0;
print(a); // 1,2
print(a.length); // 2

From this viewpoint -- for what are they? Seems again, `-n` notations for arrays and strings is useful as a "from the end"-sugar. So now I may propose it.

They're property names,

Thanks, I perfectly know what are they. And said myself that there is an "issue" that there's no stratification of properties/methods (by dot notation) and hash keys/array indexes (by square bracket notation). But it doesn't change fact that ES spec has concept of an "array index" -- a property name which is ToString(ToUInt32(name)) === name. Now I propose also a virtual array index which is ToString(ToInt32(name)) === name.

what you're suggesting would be a fairly dramatic change in behaviour and I would be concerned about it causing site breakages.


No any dramatic changes. ES5 standardized strings indices. Caused it dramatic changes? Nope. And this sugar (which is available in many langs) also won't I think.

I can easily imagine code that did:
var someArray = ..;
var i = someArray.length;
while(v = someArray[--i]) { .. do something... }


Didn't I show the same code in the previous message? Yeah, we discussed it on Twitter.

Which would now be wrong.


And concluded that this is a feature, not a bug. Both, Python and Ruby have the same behavior for such a `while` case. So what? It doesn't change the fact that this is still a useful sugar.

Likewise bugs that lead to code doing a[-1]=foo; would change from being "safe" to modifying the content of the actual array values.


In `-n` virtual property semantics it will modify array value -- starting from the end.

I'm sure I've had this discussion before, the fundamental problem is that ES does not really distinguish between dot and bracket property access, whereas afaik python does (i don't know about ruby).


Yes, I mentioned it myself several times (in articles and including several topics in es-discuss). Yes, Python distinguish. Ruby too. But from your position, ES already has some lacks then. E.g. Object.keys() -- what does it mean? What kind of "keys" you have found here? Or maybe `Object.getOwnPropertyNames()` ?

Still ES has concept of an "array index" (separating it from all other properties), I think a "virtual array index" is also good.

Dmitry.

--Oliver


On 11.11.2010 21:26, Dmitry A. Soshnikov wrote:
Actually, I'm still not sure myself whether I want this semantics in JS for arrays. I remember one case (some simple math task) when I was needed a[-1] and was glad that JS supports it -- I used `for (var i = -2; i < 10; i++) a[i]`, and it was very elegant decision at that moment.

There is also one lack (?) with decreasing counter loop (brought in discussion on Twitter), e.g.:

var a = [1, 2, 3], i = a.length;

while (v = a[--i]) {
  print(i, v)
}

that brings: 2,3  1,2  0,1  -1,3  -2,2  -3,1

i.e. double enumeration with this semantics. But formally, it's not a bug, but a feature -- both Python and Ruby have the same semantics in such a `while` case.

Another reason I'm still no sure about a[-1] is that JS (in contrast with the same Python and Ruby) has no stratification of normal properties -- via dot notation, and subscription properties -- via square bracket notation. I mentioned this in previous mentioned thread. And from this viewpoint, probably it's not good that o[-1] means exactly "-1" and a[-1] means a[`last`]. Don't know.

Want both -- and (probably sometimes needed) "-1", and sugar for [`last`].

Though, repeat, since ES5 brought special semantics for subscription of strings, i.e. "abc"[0] is "a", maybe it worth to make another sugar for arrays too? Btw, if yes, it will touch strings too.

Dmitry.

On 11.11.2010 13:24, Dmitry A. Soshnikov wrote:
Hello,

How likely (based on backward compats) that Harmony will support Pythonic negative indices for arrays? Ruby supports them too. There was previous indirect mention, were Brendan agreed that Harmony needs such a semantics for arrays, however, that discussion wasn't formed to something concrete.

Recently, there was the same discussion in CoffeeScript's tracker -- https://github.com/jashkenas/coffee-script/issues#issue/827 . Since Coffee uses JavaScript as its lower level, there were proposals to provide an alternative syntax for this (e.g. a[* - 1], where * means a.length, allowing this feature to be generic), though, I'm not sure this exact syntax is needed for ES. However, I mentioned there, that if Harmony itself will support this feature in Python's/Ruby's semantics, then Coffee won't need an alternative thing.

Currently, this feature may be easily implemented using proxies: https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/array-negative-indices.js (example), https://github.com/DmitrySoshnikov/es-laboratory/blob/master/src/array-negative-indices.js (implementation), however possibly it's good to have this semantics for objects with [[Class]] "Array" as native. I think it's acceptable, since we already have such alternative semantics for String objects.

Toughs?

Dmitry.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Negative indices for arrays

Allen Wirfs-Brock-2
From: [hidden email] [mailto:[hidden email]] On Behalf Of Dmitry A. Soshnikov
...

>Yes, I mentioned it myself several times (in articles and including several topics in es-discuss). Yes, Python distinguish. Ruby too. But from your position, ES already has some lacks then. E.g. Object.keys() -- what does it mean? What kind of "keys" you have found here? Or maybe `Object.getOwnPropertyNames()`?

Object.keys and Object.getOwnProertyNames are both precisely defined by ES5. keys returns the names of all non-enumerable own properties of an object.  getOwnPropertyNames returns the names of all own properties.

For example look at the results of Object.keys(new String('abc')) and Object.getOwnPropertyNames(new String('abc')) on an ES5 conforming implementation.

...
>Still ES has concept of an "array index" (separating it from all other properties), I think a "virtual array index" is also good.

Not really.  ES5 does not generally consider array elements or "array index" property names as separate or different from other properties or property names.  According to the ES5 spec. (15.4) "array index"  is a term used to talk about property names that conform to a specific requirement (ToString(ToUint32(name) ) === name and ToUint32(name) !==2^32-1).

 Instances of the Array constructor has special semantics for defining and updating "array index" properties. In addition, some of Array.prototype functions that perform arithmetic on "array index" property names do it in a manner that ensures results are also "array index" names.  Other than that ES5 doesn't define any special semantics for "array index" properties.  Implementations are free to optimize how they store array index properties (and many implementations do) but they are also free to optimize the storage of any property as long as the optimization maintains the observable ES5 semantics.

[from a different message]
> ES5 brought special semantics for subscription of strings, i.e. "abc"[0] is "a", maybe it worth to make another sugar for arrays too?
Actually, all that ES5 did was specify that String objects (not string values) have non-writable, non-configurable properties corresponding to the individual characters of the encapsulated string value.  "abc"[0] is really equivalent to (new String("abc"))[0]

>Btw, if yes, it will touch strings too.
Presumably, any object with a 'length' property.

As Oliver said, this would break any code that currently uses property names like "-1".  This isn't just syntactic sugar. It also has all sorts of complications relating to the basic property access semantics.  Getting this right would probably require a major redesign of ECMAScript object/property semantics in a manner that I wouldn't anticipate happening anytime soon.

Allen




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Dmitry Soshnikov
On 12.11.2010 0:07, Allen Wirfs-Brock wrote:
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Dmitry A. Soshnikov
> ...
>
>> Yes, I mentioned it myself several times (in articles and including several topics in es-discuss). Yes, Python distinguish. Ruby too. But from your position, ES already has some lacks then. E.g. Object.keys() -- what does it mean? What kind of "keys" you have found here? Or maybe `Object.getOwnPropertyNames()`?
> Object.keys and Object.getOwnProertyNames are both precisely defined by ES5. keys returns the names of all non-enumerable own properties of an object.  getOwnPropertyNames returns the names of all own properties.
>

I think it should went without saying that I meant "what kind of "keys"
have you found here if there are only properties?". Just to underline
that ES already has in some aspects some alternative meanings but not
just a "property name" (though, still keeping _only_ property names
concept).

Once again, thanks for the clarifications, but I perfectly understand
and am aware about the difference. ES-3 and ES-5 specs are out, everyone
can read it. So I did already.

> For example look at the results of Object.keys(new String('abc')) and Object.getOwnPropertyNames(new String('abc')) on an ES5 conforming implementation.
>
> ...
>> Still ES has concept of an "array index" (separating it from all other properties), I think a "virtual array index" is also good.
> Not really.  ES5 does not generally consider array elements or "array index" property names as separate or different from other properties or property names.  According to the ES5 spec. (15.4) "array index"  is a term used to talk about property names that conform to a specific requirement (ToString(ToUint32(name) ) === name and ToUint32(name) !==2^32-1).
>

Thanks again, I'm (was) aware about it.

>   Instances of the Array constructor has special semantics for defining and updating "array index" properties. In addition, some of Array.prototype functions that perform arithmetic on "array index" property names do it in a manner that ensures results are also "array index" names.  Other than that ES5 doesn't define any special semantics for "array index" properties.  Implementations are free to optimize how they store array index properties (and many implementations do) but they are also free to optimize the storage of any property as long as the optimization maintains the observable ES5 semantics.
>

About this too, thanks.

And I propose for array instances in addition to have special semantics
for handling of "virtual array index" properties. That is  
ToString(ToInt32(name)) === name with handling correctly ranges.

> [from a different message]
>> ES5 brought special semantics for subscription of strings, i.e. "abc"[0] is "a", maybe it worth to make another sugar for arrays too?
> Actually, all that ES5 did was specify that String objects (not string values) have non-writable, non-configurable properties corresponding to the individual characters of the encapsulated string value.  "abc"[0] is really equivalent to (new String("abc"))[0]
>

Yep, thanks, I know how and when and why a primitive is converted to an
object and what's going on after that. But still it doesn't cancel the
fact that ES5 brought an alternative semantics which could/can break old
code where var s = new String("foo"); s[0] = "x"; had different semantics.

>> Btw, if yes, it will touch strings too.
> Presumably, any object with a 'length' property.
>

Yeah, it's possible to make this thing generic, though maybe also good
only for arrays. Need to more discuss, think.

> As Oliver said,

I appreciated it, but let us discuss the case. And exactly your meaning.

> this would break any code that currently uses property names like "-1".

I repeat, we tried to find and remind at least _one_ more-less serious
use-case where negaitve indices where used in the old code with array --
and can't. Do you know any? It will be useful if you show.

>   This isn't just syntactic sugar. It also has all sorts of complications relating to the basic property access semantics.  Getting this right would probably require a major redesign of ECMAScript object/property semantics in a manner that I wouldn't anticipate happening anytime soon.
>

Thanks. Though, I don't see a bit changes (how you like to described all
in dark colors :)). At maximum (if not generic) -- only [[Get]] of
arrays and strings will be affected.

So, do I understand correctly that you are against this feature and
don't like it? (Just another question -- are you aware that it used in
Python, Ruby, Perl, Coffee, other langs?)

Dmitry.

> Allen
>
>
>
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Negative indices for arrays

Peter van der Zee
In reply to this post by Allen Wirfs-Brock-2
If harmony would introduce this syntax "guarded" under a new script type, there
would at least be no danger of breaking the web (existing scripts).

However, negative "array indexes" might cause confusion when doing so
implicitly. If you asume array indexes are "just" properties it'll be hard to
debug a snippet like `while (x = arr[--i]) ...` (not my own example). While it
wouldn't be my preferred way of doing this, it's still valid and will cause very
obscure and hard to debug problems.

I guess I would like -n to map to length-n, but I'm not sure whether it's worth
the cost described above. After all, it's just sugar.

- peter


> From: [hidden email] [mailto:es-discuss-
> [hidden email]] On Behalf Of Dmitry A. Soshnikov
> ..
>
>> Yes, I mentioned it myself several times (in articles and
>> including several topics in es-discuss). Yes, Python distinguish.
>> Ruby too. But from your position, ES already has some lacks then.
>> E.g. Object.keys() -- what does it mean? What kind of "keys" you
>> have found here? Or maybe `Object.getOwnPropertyNames()`?
>>
> Object.keys and Object.getOwnProertyNames are both precisely
> defined by ES5. keys returns the names of all non-enumerable own
> properties of an object.  getOwnPropertyNames returns the names of
> all own properties.
>
> For example look at the results of Object.keys(new String('abc'))
> and Object.getOwnPropertyNames(new String('abc')) on an ES5
> conforming implementation.
>
> ..
>> Still ES has concept of an "array index" (separating it from all
>> other properties), I think a "virtual array index" is also good.
>>
> Not really.  ES5 does not generally consider array elements or
> "array index" property names as separate or different from other
> properties or property names.  According to the ES5 spec. (15.4)
> "array index"  is a term used to talk about property names that
> conform to a specific requirement (ToString(ToUint32(name) ) ===
> name and ToUint32(name) !==2^32-1).
>
> Instances of the Array constructor has special semantics for
> defining and updating "array index" properties. In addition, some
> of Array.prototype functions that perform arithmetic on "array
> index" property names do it in a manner that ensures results are
> also "array index" names.  Other than that ES5 doesn't define any
> special semantics for "array index" properties.  Implementations
> are free to optimize how they store array index properties (and
> many implementations do) but they are also free to optimize the
> storage of any property as long as the optimization maintains the
> observable ES5 semantics.
>
> [from a different message]
>> ES5 brought special semantics for subscription of strings, i.e.
>> "abc"[0] is "a", maybe it worth to make another sugar for arrays
>> too?
> Actually, all that ES5 did was specify that String objects (not
> string values) have non-writable, non-configurable properties
> corresponding to the individual characters of the encapsulated
> string value.  "abc"[0] is really equivalent to (new
> String("abc"))[0]
>
>> Btw, if yes, it will touch strings too.
> Presumably, any object with a 'length' property.
>
> As Oliver said, this would break any code that currently uses
> property names like "-1".  This isn't just syntactic sugar. It also
> has all sorts of complications relating to the basic property
> access semantics.  Getting this right would probably require a
> major redesign of ECMAScript object/property semantics in a manner
> that I wouldn't anticipate happening anytime soon.
>
> Allen
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Oliver Hunt-2
In reply to this post by Dmitry Soshnikov
>
> So, do I understand correctly that you are against this feature and don't like it? (Just another question -- are you aware that it used in Python, Ruby, Perl, Coffee, other langs?)
The fact that other languages have a feature is not relevant, the problem is the drastic change to semantics of property access.  In a way that is incompatible with existing behaviour.  It is not syntactic sugar.  Syntactic sugar takes something that would fail to run in the past, and makes it do something "helpful" instead.  You want to take a syntax that does one thing, and change its behaviour entirely.

--Oliver

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Dmitry Soshnikov
In reply to this post by Peter van der Zee
On 12.11.2010 0:42, Peter van der Zee wrote:
> If harmony would introduce this syntax "guarded" under a new script type, there
> would at least be no danger of breaking the web (existing scripts).
>

I don't think it means that using <script type="harmony"> we may do
"everything" (i.e. completely different syntax and skin).

> However, negative "array indexes" might cause confusion when doing so
> implicitly. If you asume array indexes are "just" properties it'll be hard to
> debug a snippet like `while (x = arr[--i]) ...` (not my own example).

Why this example is repeated already third time here? ;) Yes, we aware
about it, and as said, it's a feature, not a bug.

>   While it
> wouldn't be my preferred way of doing this, it's still valid and will cause very
> obscure and hard to debug problems.
>
> I guess I would like -n to map to length-n, but I'm not sure whether it's worth
> the cost described above. After all, it's just sugar.
>

But again, it's not a bug. Both, Ruby and Python has the same semantics
in such case at the same time having `-n` as a sugar:

Ruby:

a = [1, 2, 3];
a[-1] # 3

i = 2

while (v = a[i]) do
   print i, v
   i -= 1
end

Result: 2,3  1,2  1,0  -1,3  -2,2  -3,0

Python:

a = [1, 2, 3]
a[-1] # 3
i = 2

while a[i]:
     print(i, a[i])
     i = i - 1

Result: 2,3  1,2  1,0  -1,3  -2,2  -3,0


> - peter
>
>
>> From: [hidden email] [mailto:es-discuss-
>> [hidden email]] On Behalf Of Dmitry A. Soshnikov
>> ..
>>
>>> Yes, I mentioned it myself several times (in articles and
>>> including several topics in es-discuss). Yes, Python distinguish.
>>> Ruby too. But from your position, ES already has some lacks then.
>>> E.g. Object.keys() -- what does it mean? What kind of "keys" you
>>> have found here? Or maybe `Object.getOwnPropertyNames()`?
>>>
>> Object.keys and Object.getOwnProertyNames are both precisely
>> defined by ES5. keys returns the names of all non-enumerable own
>> properties of an object.  getOwnPropertyNames returns the names of
>> all own properties.
>>
>> For example look at the results of Object.keys(new String('abc'))
>> and Object.getOwnPropertyNames(new String('abc')) on an ES5
>> conforming implementation.
>>
>> ..
>>> Still ES has concept of an "array index" (separating it from all
>>> other properties), I think a "virtual array index" is also good.
>>>
>> Not really.  ES5 does not generally consider array elements or
>> "array index" property names as separate or different from other
>> properties or property names.  According to the ES5 spec. (15.4)
>> "array index"  is a term used to talk about property names that
>> conform to a specific requirement (ToString(ToUint32(name) ) ===
>> name and ToUint32(name) !==2^32-1).
>>
>> Instances of the Array constructor has special semantics for
>> defining and updating "array index" properties. In addition, some
>> of Array.prototype functions that perform arithmetic on "array
>> index" property names do it in a manner that ensures results are
>> also "array index" names.  Other than that ES5 doesn't define any
>> special semantics for "array index" properties.  Implementations
>> are free to optimize how they store array index properties (and
>> many implementations do) but they are also free to optimize the
>> storage of any property as long as the optimization maintains the
>> observable ES5 semantics.
>>
>> [from a different message]
>>> ES5 brought special semantics for subscription of strings, i.e.
>>> "abc"[0] is "a", maybe it worth to make another sugar for arrays
>>> too?
>> Actually, all that ES5 did was specify that String objects (not
>> string values) have non-writable, non-configurable properties
>> corresponding to the individual characters of the encapsulated
>> string value.  "abc"[0] is really equivalent to (new
>> String("abc"))[0]
>>
>>> Btw, if yes, it will touch strings too.
>> Presumably, any object with a 'length' property.
>>
>> As Oliver said, this would break any code that currently uses
>> property names like "-1".  This isn't just syntactic sugar. It also
>> has all sorts of complications relating to the basic property
>> access semantics.  Getting this right would probably require a
>> major redesign of ECMAScript object/property semantics in a manner
>> that I wouldn't anticipate happening anytime soon.
>>
>> Allen
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Dmitry Soshnikov
In reply to this post by Oliver Hunt-2
On 12.11.2010 0:47, Oliver Hunt wrote:
>> So, do I understand correctly that you are against this feature and don't like it? (Just another question -- are you aware that it used in Python, Ruby, Perl, Coffee, other langs?)
> The fact that other languages have a feature is not relevant, the problem is the drastic change to semantics of property access.  In a way that is incompatible with existing behaviour.  It is not syntactic sugar.  Syntactic sugar takes something that would fail to run in the past, and makes it do something "helpful" instead.  You want to take a syntax that does one thing, and change its behaviour entirely.
>

I understand what I want and what I propose.

OK, so, do I understand that you also (as Allen) against this feature
and don't like it?

Another question -- still, can you remind at least one more-less serious
use-case when `-n` were heavily used with arrays? I repeat, we tried --
and couldn't. Maybe you will, it will be useful -- to analyze whether we
need such a sugar or not and what will it break, but not just abstract
talks about "it will dramatically crash everything old".

Thanks.

Dmitry.

> --Oliver
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Negative indices for arrays

Allen Wirfs-Brock-2
In reply to this post by Dmitry Soshnikov
> -----Original Message-----
> From: Dmitry A. Soshnikov [mailto:[hidden email]]
...
>
> Yeah, it's possible to make this thing generic, though maybe also good only for
> arrays. Need to more discuss, think.
>
There isn't actually all that much difference between array instances and non-array objects with array index properties. ES5 went in the direction of making sure that array functions all worked on arbitrary objects.  I don't think we would want to go backwards on that.

...
> > this would break any code that currently uses property names like "-1".
>
> I repeat, we tried to find and remind at least _one_ more-less serious use-case
> where negaitve indices where used in the old code with array -- and can't. Do
> you know any? It will be useful if you show.
>
Anybody who is using an object (possibly an array instance) as a hash table with signed integer keys


> >   This isn't just syntactic sugar. It also has all sorts of complications relating to
> the basic property access semantics.  Getting this right would probably require a
> major redesign of ECMAScript object/property semantics in a manner that I
> wouldn't anticipate happening anytime soon.
> >
>
> Thanks. Though, I don't see a bit changes (how you like to described all in dark
> colors :)). At maximum (if not generic) -- only [[Get]] of arrays and strings will be
> affected.
And presumably [[Put]] and as some sort of dynamic parsing of string property names and for generic object support check for a length property, etc.

>
> So, do I understand correctly that you are against this feature and don't like it?
> (Just another question -- are you aware that it used in Python, Ruby, Perl,
> Coffee, other langs?)
>
I have no problem with this feature as it appears in other languages.  I'm just saying that it doesn't appear to fit well with JavaScript's property semantics.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Negative indices for arrays

Allen Wirfs-Brock-2
In reply to this post by Peter van der Zee
> -----Original Message-----
> From: Peter van der Zee [mailto:[hidden email]]
...
> I guess I would like -n to map to length-n, but I'm not sure whether it's worth the
> cost described above. After all, it's just sugar.
>

Like Oliver also said.  This isn't just sugar, it is a deep semantic change to the interpretation of property names
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Dave Herman
In reply to this post by Peter van der Zee
> If harmony would introduce this syntax "guarded" under a new script type, there
> would at least be no danger of breaking the web (existing scripts).

That sounds like an interop nightmare -- you're talking about forking the Array type between language versions. Keep in mind that non-Harmony and Harmony code will be able to interact in the same page.

Dave

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Brendan Eich-3
I agree with Dave, Allen, and Oliver that we should not just change indexing under Harmony script-type opt-in.

Note also that Python, at least, has a more elaborate system of slicing that has evolved over the years. I added slice in the Netscape 4 era, which made it into ES3 and has the desired negative index behavior, but other additions from that era (some from Perl!) do not match, and anyway, the array-index-is-a-property-name ship had sailed in 1995.

If we were to develop a generic slice proposal with new syntax, then I think it would be crazy not to follow Python's (and ES3-5's slice method's) lead and support negative indexing. This would not break existing code because it would happen only with new syntax and new functions or methods.

The obvious slice syntax is a[i:j] for a slice of a from index i up to but not including index j, with negative indexes supported as from the end, and with indexes on either side of : optional, defaulting as in Python.

If : is problematic we could try CoffeeScript's .., but .. and ... as well as . in the language may be too much. The syntax is not as important as the semantics at this point, but one more syntax observation:

The [:] syntax fits in Python, where a[-1] is the last element of the sequence a. But since we don't want to make that change to JS arrays, this slice syntax is not so attractive. It will mislead Python folks into using negative indexes with property accesses as well as with slices.

Ruby does not dedicate syntax, using methods instead (Smalltalk-y, as one would hope).

This seems much more promising for Harmony than new slice or from-the-end indexing syntax, since we already have Array and String slice methods that do the right thing with negative indexes. We have String charAt/charCodeAt but part of the appeal of slicing and negative indexing is how they work on all sequence types in Python.

An Array and String get method that takes an index, which can be negative, would complement slice. Array would want a set or put method too. Names need tuning, but they ought to be short.

/be

On Nov 11, 2010, at 3:25 PM, David Herman wrote:

>> If harmony would introduce this syntax "guarded" under a new script type, there
>> would at least be no danger of breaking the web (existing scripts).
>
> That sounds like an interop nightmare -- you're talking about forking the Array type between language versions. Keep in mind that non-Harmony and Harmony code will be able to interact in the same page.
>
> Dave
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Negative indices for arrays

Dmitry Soshnikov
In reply to this post by Allen Wirfs-Brock-2
On 12.11.2010 1:17, Allen Wirfs-Brock wrote:
>> -----Original Message-----
>> From: Dmitry A. Soshnikov [mailto:[hidden email]]
> ...
>> Yeah, it's possible to make this thing generic, though maybe also good only for
>> arrays. Need to more discuss, think.
>>
> There isn't actually all that much difference between array instances and non-array objects with array index properties. ES5 went in the direction of making sure that array functions all worked on arbitrary objects.  I don't think we would want to go backwards on that.
>

Yeah, however, I think it's mostly not about generic methods, but about
overloaded [[Get]] / [[Put]]. And in ES3 and ES5 overloaded [[Put]] /
[[DefineOwnProperty]] is not generic but special for arrays. The same I
assume this feature is special for arrays. Really, I don't see any big
issues with backward compats. They are so minimal that may be ignored.


> ...
>>> this would break any code that currently uses property names like "-1".
>> I repeat, we tried to find and remind at least _one_ more-less serious use-case
>> where negaitve indices where used in the old code with array -- and can't. Do
>> you know any? It will be useful if you show.
>>
> Anybody who is using an object (possibly an array instance) as a hash table with signed integer keys
>
>

That's another case. Of course, if we'll consider the other objects,
then "-1" may be used. But, repeat, this feature (at least with the
syntax `a[-n]`) should be considered first/only for arrays.

Another thing I agree we may want to see in JS a generic such a feature,
then the alternative syntax as `a[* - 1]` may be the case. That, repeat,
will bring also a sugar for `a.push(10)` as `a[*] = 10`.


>>>    This isn't just syntactic sugar. It also has all sorts of complications relating to
>> the basic property access semantics.  Getting this right would probably require a
>> major redesign of ECMAScript object/property semantics in a manner that I
>> wouldn't anticipate happening anytime soon.
>> Thanks. Though, I don't see a bit changes (how you like to described all in dark
>> colors :)). At maximum (if not generic) -- only [[Get]] of arrays and strings will be
>> affected.
> And presumably [[Put]] and as some sort of dynamic parsing of string property names and for generic object support check for a length property, etc.
>

Yep, sure.

>> So, do I understand correctly that you are against this feature and don't like it?
>> (Just another question -- are you aware that it used in Python, Ruby, Perl,
>> Coffee, other langs?)
>>
> I have no problem with this feature as it appears in other languages.  I'm just saying that it doesn't appear to fit well with JavaScript's property semantics.

But what are suggesting at the same time? What's your meaning -- whether
JS needs a some sugar for taking elements (ok, let's say) of a sequence
starting-from-the-end or not?

Dmitry.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12