Re: Negative indices for arrays
On 12.11.2010 1:17, Allen Wirfs-Brock wrote: -Original Message- From: Dmitry A. Soshnikov [mailto:dmitry.soshni...@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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
On 12.11.2010 1:21, Allen Wirfs-Brock wrote: -Original Message- From: Peter van der Zee [mailto:e...@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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
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. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
2010/11/12 Dmitry A. Soshnikov dmitry.soshni...@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. -- Erik Corry ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
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 --
`[].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? Coffee borrows its .. (including higher index) and ...
(excluding higher index) from Ruby:
Ruby:
a = [1, 2, 3, 4]
a[-1] # 4
a[0..2] # [1,2,3]
a[0...2] # [1,2]
(need to say, that for me .. and ... should be logically inverted: i.e.
... should include, and .. -- exclude).
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.
Yes, regarding slice -- yes. And moreover, they are generic.
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.
Absolutely.
/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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
On 12.11.2010 12:01, Erik Corry wrote: 2010/11/12 Dmitry A. Soshnikovdmitry.soshni...@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 -- http://bit.ly/9KBxzl) -- with using proxies it's very easy to implement. Unfortunately (or fortunately -- it depends), not on `Array.prototype` (since I cannot replace it with a proxy, because of [[Configurable]] / [[Writable]] false), but with using `Array.new` semantics. It may be even used. Though, without a big wide-spreading (as in other langs), it will be just an academic curiosity without practical usage. Dmitry. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
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 http://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
http://i.i.com.com/cnwk.1d/html/rb/js/tron/oreo.moo.rb.combined.js:6:-1
http://i.zdnet.com/js/mootools-core-more.js:3:-1
http://l.yimg.com/a/combo?metro/tuc/tuc_outboxlite_0.0.29.jsmetro/contentcarousel/contentcarousel_0.1.40.jsmetro/contentcarousel/contentcarouseladserved_0.1.6.jsmetro/uiplugins/toolbar_bridge_service_0.1.18.jsmetro/uiplugins/tooltip_service_0.1.47.jsmetro/uiplugins/sortable_service_0.1.20.jsmetro/pa/pautil_0.1.4.jsmetro/pa/palist_0.1.23.jsmetro/pa/pa_0.1.218.jsmetro2/multimedia/multimedia_0.0.6.jsmetro/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.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: { and } in regexps
I don't think so. See
http://blogs.msdn.com/b/ie/archive/2010/08/25/chakra-interoperability-means-more-than-just-standards.aspx
Hopefully for Harmony somebody will take on the challenge of updating the
RegExp spec. to reflect reality. We need a software archeologist to analyze
the major browsers what the consensus spec. really is.
Allen
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Michael Day
Sent: Thursday, November 11, 2010 11:59 PM
To: ES-Discuss
Subject: { and } in regexps
Hi,
Browsers seem to allow { and } to occur in regexps unescaped, if the position
does not conflict with their use as a quantifier. For example:
/foo|{bar}/
However, ES3 and ES5 forbid this, as PatternCharacter does not include { or }
or
any of the other significant punctuation.
Given that every new implementation ends up having to do what all the existing
implementations do, is there any reason for the spec to differ?
Best regards,
Michael
--
Print XML with Prince!
http://www.princexml.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: { and } in regexps
On Nov 12, 2010, at 8:08 AM, Allen Wirfs-Brock wrote:
I don't think so. See
http://blogs.msdn.com/b/ie/archive/2010/08/25/chakra-interoperability-means-more-than-just-standards.aspx
Hopefully for Harmony somebody will take on the challenge of updating the
RegExp spec. to reflect reality. We need a software archeologist to analyze
the major browsers what the consensus spec. really is.
We have such an archeologist, in my opinion. See
http://blog.stevenlevithan.com/
https://bugzilla.mozilla.org/buglist.cgi?emailassigned_to1=1query_format=advancedemailcc1=1emaillongdesc1=1bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDemail1=steves_listemailtype1=substring
/be
Allen
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Michael Day
Sent: Thursday, November 11, 2010 11:59 PM
To: ES-Discuss
Subject: { and } in regexps
Hi,
Browsers seem to allow { and } to occur in regexps unescaped, if the position
does not conflict with their use as a quantifier. For example:
/foo|{bar}/
However, ES3 and ES5 forbid this, as PatternCharacter does not include { or
} or
any of the other significant punctuation.
Given that every new implementation ends up having to do what all the
existing
implementations do, is there any reason for the spec to differ?
Best regards,
Michael
--
Print XML with Prince!
http://www.princexml.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
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 http://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
http://i.i.com.com/cnwk.1d/html/rb/js/tron/oreo.moo.rb.combined.js:6:-1
http://i.zdnet.com/js/mootools-core-more.js:3:-1
http://l.yimg.com/a/combo?metro/tuc/tuc_outboxlite_0.0.29.jsmetro/contentcarousel/contentcarousel_0.1.40.jsmetro/contentcarousel/contentcarouseladserved_0.1.6.jsmetro/uiplugins/toolbar_bridge_service_0.1.18.jsmetro/uiplugins/tooltip_service_0.1.47.jsmetro/uiplugins/sortable_service_0.1.20.jsmetro/pa/pautil_0.1.4.jsmetro/pa/palist_0.1.23.jsmetro/pa/pa_0.1.218.jsmetro2/multimedia/multimedia_0.0.6.jsmetro/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.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
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).
/be
On Nov 12, 2010, at 1:25 PM, Dmitry A. Soshnikov wrote:
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 http://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
http://i.i.com.com/cnwk.1d/html/rb/js/tron/oreo.moo.rb.combined.js:6:-1
http://i.zdnet.com/js/mootools-core-more.js:3:-1
http://l.yimg.com/a/combo?metro/tuc/tuc_outboxlite_0.0.29.jsmetro/contentcarousel/contentcarousel_0.1.40.jsmetro/contentcarousel/contentcarouseladserved_0.1.6.jsmetro/uiplugins/toolbar_bridge_service_0.1.18.jsmetro/uiplugins/tooltip_service_0.1.47.jsmetro/uiplugins/sortable_service_0.1.20.jsmetro/pa/pautil_0.1.4.jsmetro/pa/palist_0.1.23.jsmetro/pa/pa_0.1.218.jsmetro2/multimedia/multimedia_0.0.6.jsmetro/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.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Re: Suggested RegExp Improvements
After considering all the breadth this discussion could take maybe it would be wise to just focus on one issue at a time. For me, the biggest missing feature is lookbehind. Its common to most languages implementing the Perl-RegExp-syntax, it is very useful when looking for patterns that follow or don't follow a particular pattern. I guess I'm confused why lookahead made it in but not lookbehind. What do people think about including this feature? Marc On Fri, 2010-11-12 at 16:20 -0600, Marc Harter wrote: I will start out with a disclaimer. I have not read both ECMAScript specifications for 3 and now 5, so I admit that I am not an expert in the spec itself but as I user of JavaScript, I would like to get some expert discussion over this topic as proposed enhancements to the RegExp engine for Harmony. I will start with a list of lacking features in JS as compared to Perl provided by (http://www.regular-expressions.info/javascript.html): * No \A or \Z anchors to match the start or end of the string. Use a caret or dollar instead. * Lookbehind is not supported at all. Lookahead is fully supported. * No atomic grouping or possessive quantifiers * No Unicode support, except for matching single characters with \u * No named capturing groups. Use numbered capturing groups instead. * No mode modifiers to set matching options within the regular expression. * No conditionals. * No regular expression comments. Describe your regular expression with JavaScript // comments instead, outside the regular expression string. I don't know if all of these need to be in the language but there have been some that I have personally wanted to use: * Lookbehind! ECMAScript fully supports lookahead, why not lookbehind? Seems like a big hole to me. * Named capturing groups and comments (e.g. http://xregexp.com/syntax/). Mostly I argue for this because it makes RegExp matches more self-documenting. Regular Expressions are already cryptic as it is. I do like some of the new flags proposed in (http://xregexp.com/flags/) but personally haven't used them but maybe that is something also for discussion. Marc Harter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggested RegExp Improvements
On Nov 12, 2010, at 2:52 PM, Marc Harter wrote: After considering all the breadth this discussion could take maybe it would be wise to just focus on one issue at a time. For me, the biggest missing feature is lookbehind. Its common to most languages implementing the Perl-RegExp-syntax, it is very useful when looking for patterns that follow or don't follow a particular pattern. I guess I'm confused why lookahead made it in but not lookbehind. This was 1998, Netscape 4 work I did in '97 was based on Perl 4(!), but we proposed to ECMA TC39 TG1 (the JS group -- things were different then, including capitalization) something based on Perl 5. We didn't get everything, and we had to rationalize some obvious quirks. I don't remember lookbehind (which emerged in Perl 5.005 in July '98) being left out on purpose. Waldemar may recall more, I'd handed him the JS keys inside netscape.com to go do mozilla.org. If you are game to write a proposal or mini-spec (in the style of ES5 even), let me know. I'll chat with other TC39'ers next week about this. /be What do people think about including this feature? Marc On Fri, 2010-11-12 at 16:20 -0600, Marc Harter wrote: I will start out with a disclaimer. I have not read both ECMAScript specifications for 3 and now 5, so I admit that I am not an expert in the spec itself but as I user of JavaScript, I would like to get some expert discussion over this topic as proposed enhancements to the RegExp engine for Harmony. I will start with a list of lacking features in JS as compared to Perl provided by (http://www.regular-expressions.info/javascript.html): * No \A or \Z anchors to match the start or end of the string. Use a caret or dollar instead. * Lookbehind is not supported at all. Lookahead is fully supported. * No atomic grouping or possessive quantifiers * No Unicode support, except for matching single characters with \u * No named capturing groups. Use numbered capturing groups instead. * No mode modifiers to set matching options within the regular expression. * No conditionals. * No regular expression comments. Describe your regular expression with JavaScript // comments instead, outside the regular expression string. I don't know if all of these need to be in the language but there have been some that I have personally wanted to use: * Lookbehind! ECMAScript fully supports lookahead, why not lookbehind? Seems like a big hole to me. * Named capturing groups and comments (e.g. http://xregexp.com/syntax/). Mostly I argue for this because it makes RegExp matches more self-documenting. Regular Expressions are already cryptic as it is. I do like some of the new flags proposed in (http://xregexp.com/flags/) but personally haven't used them but maybe that is something also for discussion. Marc Harter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggested RegExp Improvements
On 11/12/10 15:04, Brendan Eich wrote: On Nov 12, 2010, at 2:52 PM, Marc Harter wrote: After considering all the breadth this discussion could take maybe it would be wise to just focus on one issue at a time. For me, the biggest missing feature is lookbehind. Its common to most languages implementing the Perl-RegExp-syntax, it is very useful when looking for patterns that follow or don't follow a particular pattern. I guess I'm confused why lookahead made it in but not lookbehind. This was 1998, Netscape 4 work I did in '97 was based on Perl 4(!), but we proposed to ECMA TC39 TG1 (the JS group -- things were different then, including capitalization) something based on Perl 5. We didn't get everything, and we had to rationalize some obvious quirks. I don't remember lookbehind (which emerged in Perl 5.005 in July '98) being left out on purpose. Waldemar may recall more, I'd handed him the JS keys inside netscape.com to go do mozilla.org. If you are game to write a proposal or mini-spec (in the style of ES5 even), let me know. I'll chat with other TC39'ers next week about this. The ES3 spec was based on what was stable at the time. Perl had been experimenting with other constructs in regexp's, but there was some churn there, and I didn't want to go for features that were still in flux. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
