Discuss
  • Negative indices for arrays

Negative indices for arrays

# Dmitry A. Soshnikov (14 years ago)

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

# Dmitry A. Soshnikov (14 years ago)

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 esdiscuss/2010-May/011115

# Dmitry A. Soshnikov (14 years ago)

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

Toughs?

Funny typo :D Sorry.

Thoughts?

# Dmitry A. Soshnikov (14 years ago)

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.

# Dmitry A. Soshnikov (14 years ago)

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.

# Oliver Hunt (14 years ago)

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).

# Ash Berlin (14 years ago)

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.

# Dmitry A. Soshnikov (14 years ago)

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.

# Dmitry A. Soshnikov (14 years ago)

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

# Allen Wirfs-Brock (14 years ago)

From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] 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.

# Dmitry A. Soshnikov (14 years ago)

On 12.11.2010 0:07, Allen Wirfs-Brock wrote:

From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] 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

# Peter van der Zee (14 years ago)

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.

# Oliver Hunt (14 years ago)

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.

# Dmitry A. Soshnikov (14 years ago)

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

# Dmitry A. Soshnikov (14 years ago)

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

# Allen Wirfs-Brock (14 years ago)

-----Original Message----- From: Dmitry A. Soshnikov [mailto:dmitry.soshnikov at gmail.com] ...

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.

# Allen Wirfs-Brock (14 years ago)

-----Original Message----- From: Peter van der Zee [mailto:ecma at qfox.nl] ... 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

# David Herman (14 years ago)

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.

# Brendan Eich (14 years ago)

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.

# Dmitry A. Soshnikov (14 years ago)

On 12.11.2010 1:17, Allen Wirfs-Brock wrote:

-----Original Message----- From: Dmitry A. Soshnikov [mailto:dmitry.soshnikov at gmail.com] ... 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.

# Dmitry A. Soshnikov (14 years ago)

On 12.11.2010 1:21, Allen Wirfs-Brock wrote:

-----Original Message----- From: Peter van der Zee [mailto:ecma at qfox.nl] ... 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.

Like everybody on this list understands what it is.

This isn't just sugar, it is a deep semantic change to the interpretation of property names

As I see it:

  1. if to consider only for arrays -- it's a minimal semantics changes and minimal backward compats.
  2. if to make it generic, we need another syntax.

What do you suggest?

Dmitry.

# Dmitry A. Soshnikov (14 years ago)

On 12.11.2010 2:25, 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.

Agreed, it will be very hard to combine different semantics on the same page; it's not the case.

# Erik Corry (14 years ago)

2010/11/12 Dmitry A. Soshnikov <dmitry.soshnikov at gmail.com>:

What do you suggest?

I suggest you monkey patch a get method on the Array prototype and forget trying to get the language semantics changed. The people who implement the language have made their opinions clear and as of this post that includes V8.

# Dmitry A. Soshnikov (14 years ago)

On 12.11.2010 2:40, Brendan Eich wrote:

I agree with Dave, Allen, and Oliver

That's OK.

I consider several variants also. As Allen mentioned, if it will be a generic thing, then foo[-n] may break an old code (and then we need another syntax e.g. a[* - 1] -- if need at all then!). OTOH, if only for arrays -- I don't see any big real practical issues.

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.

Of course it had sailed. But the thing is nobody (?) on that ship used negative-array-index in old code -- in a some more-less serious real practical application. So it may be re-borrowed and put on the next ship. However, not necessary in this view -- a[-1]. If generic, -- with another syntax.

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.

Absolutely.

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,

So, can we stop at this point? I mean -- if we really don't want this changes, then the question may be closed, I guess. Just acknowledge it.

this slice syntax is not so attractive. It will mislead Python folks into using negative indexes with property accesses as well as with slices.

Yeah, true. Though, maybe nevertheless to completely port Python's slicing for arrays? ;P I liked this idea. But -- only for arrays, not generic then. Unfortunatelly, it may break current generic slice

# Dmitry A. Soshnikov (14 years ago)

On 12.11.2010 12:01, Erik Corry wrote:

2010/11/12 Dmitry A. Soshnikov<dmitry.soshnikov at gmail.com>:

What do you suggest? I suggest you monkey patch a get method on the Array prototype and forget trying to get the language semantics changed. The people who implement the language have made their opinions clear and as of this post that includes V8.

Sure. And already have done (as mentioned in the initial message

# Brendan Eich (14 years ago)

On Nov 12, 2010, at 1:01 AM, Dmitry A. Soshnikov wrote:

I consider several variants also. As Allen mentioned, if it will be a generic thing, then foo[-n] may break an old code (and then we need another syntax e.g. a[* - 1] -- if need at all then!). OTOH, if only for arrays -- I don't see any big real practical issues.

It is dangerous to make assertions based on wishes, instead of gathering data (see below).

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.

Of course it had sailed. But the thing is nobody (?) on that ship used negative-array-index in old code -- in a some more-less serious real practical application.

You do keep asserting that. :-|

Though, maybe nevertheless to completely port Python's slicing for arrays? ;P I liked this idea. But -- only for arrays, not generic then. Unfortunatelly, it may break current generic slice -- [].slice.call({0:1, 1:2, length:2}, -1)[0] // 2.

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

How that?

I was referring to slice.

Ok, data: I added logging code to detect whenever an array is accessed via a negative index to my custom hg.mozilla.org/tracemonkey Firefox build. Here after a few minutes of browsing is the log file, piped through sort -u (there are many repeated entries):

file:///Users/brendaneich/Hacking/hg.mozilla.org/tracemonkey/OBJ/dist/MinefieldDebug.app/Contents/MacOS/components/nsSessionStore.js:1762:-1 i.i.com.com/cnwk.1d/html/rb/js/tron/oreo.moo.rb.combined.js:6:-1, i.zdnet.com/js/mootools-core-more.js:3:-1, l.yimg.com/a/combo?metro/tuc/tuc_outboxlite_0.0.29.js&metro/contentcarousel/contentcarousel_0.1.40.js&metro/contentcarousel/contentcarouseladserved_0.1.6.js&metro/uiplugins/toolbar_bridge_service_0.1.18.js&metro/uiplugins/tooltip_service_0.1.47.js&metro/uiplugins/sortable_service_0.1.20.js&metro/pa/pautil_0.1.4.js&metro/pa/palist_0.1.23.js&metro/pa/pa_0.1.218.js&metro2/multimedia/multimedia_0.0.6.js&metro/batchload/batchload_0.1.7.js:7:-1

I'll keep this browser running for a bit, but it is clear "somebody" used negative array indexes. And it would be no fun finding such dynamic occurrences when porting if we made negative indexes work as in Python in Harmony.

In general, taking ES5 strict code into Harmony should not require porting, other than removing any dependencies on global variable vs global object property aliasing.

# Dmitry A. Soshnikov (14 years ago)

Brendan, thanks for the analysis and tests, possibly it's useful. Also, I think that a proposal can look more like a proposal (and not like I'm very want to include something into the language, and other members resist it), I'm not sure we need to prove something in this case. If everybody on the lists have decided that this is not needed for ECMAScript -- that's completely OK.

(Below some small additions)

On 12.11.2010 18:40, Brendan Eich wrote:

On Nov 12, 2010, at 1:01 AM, Dmitry A. Soshnikov wrote:

I consider several variants also. As Allen mentioned, if it will be a generic thing, then foo[-n] may break an old code (and then we need another syntax e.g. a[* - 1] -- if need at all then!). OTOH, if only for arrays -- I don't see any big real practical issues. It is dangerous to make assertions based on wishes, instead of gathering data (see below).

Sure.

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. Of course it had sailed. But the thing is nobody (?) on that ship used negative-array-index in old code -- in a some more-less serious real practical application. You do keep asserting that. :-|

Of course. Though, we may say that neither Allen (including Erick from V8), nor Oliver didn't even asserted. Just some abstract "dramatic", "critical" breaking of the old code. But in real, I didn't see it. Your tests with logging maybe prove something, but hardly it's an absolute and real results. Anyway, it's something.

Though, maybe nevertheless to completely port Python's slicing for arrays? ;P I liked this idea. But -- only for arrays, not generic then. Unfortunatelly, it may break current generic slice -- [].slice.call({0:1, 1:2, length:2}, -1)[0] // 2.

Ruby does not dedicate syntax, using methods instead (Smalltalk-y, as one would hope). How that? I was referring to slice.

Hm... These are slices:

a = [1, 2, 3, 4] a[0..2] # 1,2,3 a[1..-1] # 2,3,4

a[-1..-1] # 4 a[-1] # the same, 4

Btw, in ES, slice being able to slice:

a.slice(-2, -1); // [3]

unable to slice:

a.slice(-2, -1); // []

and requires:

a.slice(-1)[0]; // 4

but this is -- JFTR.

Ok, data: I added logging code to detect whenever an array is accessed via a negative index to my custom hg.mozilla.org/tracemonkey Firefox build. Here after a few minutes of browsing is the log file, piped through sort -u (there are many repeated entries):

file:///Users/brendaneich/Hacking/hg.mozilla.org/tracemonkey/OBJ/dist/MinefieldDebug.app/Contents/MacOS/components/nsSessionStore.js:1762:-1 i.i.com.com/cnwk.1d/html/rb/js/tron/oreo.moo.rb.combined.js:6:-1, i.zdnet.com/js/mootools-core-more.js:3:-1, l.yimg.com/a/combo?metro/tuc/tuc_outboxlite_0.0.29.js&metro/contentcarousel/contentcarousel_0.1.40.js&metro/contentcarousel/contentcarouseladserved_0.1.6.js&metro/uiplugins/toolbar_bridge_service_0.1.18.js&metro/uiplugins/tooltip_service_0.1.47.js&metro/uiplugins/sortable_service_0.1.20.js&metro/pa/pautil_0.1.4.js&metro/pa/palist_0.1.23.js&metro/pa/pa_0.1.218.js&metro2/multimedia/multimedia_0.0.6.js&metro/batchload/batchload_0.1.7.js:7:-1

I'll keep this browser running for a bit, but it is clear "somebody" used negative array indexes. And it would be no fun finding such dynamic occurrences when porting if we made negative indexes work as in Python in Harmony.

Maybe they tried to apply exactly Python's semantics while were testing? :D But seriously, yep, the test may say something.

In general, taking ES5 strict code into Harmony should not require porting, other than removing any dependencies on global variable vs global object property aliasing.

OK, so since all are against, I think the proposal (if is not required hard) may be canceled.

Thanks again.

Dmitry.

# Dmitry A. Soshnikov (14 years ago)

On 13.11.2010 0:25, Dmitry A. Soshnikov wrote:

unable to slice:

a.slice(-2, -1); // []

Sorry, typo; meant a.slice(-1, -1); []

Dmitry.

# felix (14 years ago)

the D language handles this by having the names '$' and 'length' be the length of the array, within the scope of a [] subscript, so you can say something like a[$-1]. '$' is already too widely used in js, but maybe something like '_' would work. say, if there's no declaration of _ in scope, then _ within [] is the length of the array.

# Dmitry A. Soshnikov (14 years ago)

On 13.11.2010 0:52, felix wrote:

the D language handles this by having the names '$' and 'length' be the length of the array, within the scope of a [] subscript, so you can say something like a[$-1]. '$' is already too widely used in js, but maybe something like '_' would work. say, if there's no declaration of _ in scope, then _ within [] is the length of the array.

$ and _ -- both are valid identifiers which may already have values. Though, $ is used in regexp and isn't confused with the same name identifier. With the same success any other could be accepted. But, as said -- everyone on this list do not see the need.

Dmitry.

# Brendan Eich (14 years ago)

I would have liked negative indexes for bracket-indexing from the end, and I suspect others who knew "in their bones" that it's too incompatible of a change would too -- we just knew it was not going to be a non-breaking change.

It's very hard to change subtle features that the Web comes to depend on. I've only seen building better mousetraps, leading people away from the old trap, work over time. It's not a speedy process, especially if the subtle feature is not a misfeature (but people disagree on this difference -- 'with' is still with us, some people actually defend and use it).