How about replacing <| with ->
It was recently suggest to me that it is unlikely that we will ever adopt -> as as function expression shorthand symbol and that this means we could consider using that symbol sequence for other purposes. In particular, it would be a reasonable and possibly less controversial alternative to the <| symbol. I would have no objection to that switch and have written the suggestion up at doku.php#suggestion_to_replace_with
Some examples of this usage of -> include:
MyObject.prototype -> {a:1,b:2} appArrayBehavior->[0,1,2,3,4,5] let subclass = superclass -> function () {}; var p = newRegExpMethods -> /[a-m][3-7]/
What do you think? Do you like -> better than <| ? Is it ok to not have it available for functions?
It was recently suggested to me that it is unlikely that we will ever adopt -> as as function expression shorthand symbol and that this means we could consider using that symbol sequence for other purposes. In particular, it would be a reasonable and possibly less controversial alternative to the <| symbol. I would have no objection to that switch and have written the suggestion up at doku.php#suggestion_to_replace_with
Some examples of this usage of -> include:
MyObject.prototype -> {a:1,b:2} appArrayBehavior->[0,1,2,3,4,5] let subclass = superclass -> function () {}; var p = newRegExpMethods -> /[a-m][3-7]/
What do you think? Do you like -> better than <| ? Is it ok to not have it available for some possible future function shorthand?
On Fri, Mar 2, 2012 at 2:30 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
Some examples of this usage of -> include: MyObject.prototype -> {a:1,b:2} appArrayBehavior->[0,1,2,3,4,5] let subclass = superclass -> function () {}; var p = newRegExpMethods -> /[a-m][3-7]/ What do you think? Do you like -> better than <| ? Is it ok to not have it available for some possible future function shorthand?
I’ve been contemplating a +> symbol.
prototype +> {a: 1, b: 2}
arrayExtras +> [1,2,3]
let sub = super +> function () {};
var p = regexpExtras +> /[a-m][3-7]/
There may be little precedent for abusing operators in JavaScript, but in other systems, I would expect adding collections to produce the union of those collections, with precedence given to the right hand operand. In a world where [1,2,3] + [4,5,6] = [1,2,3,4,5,6] and {a:10, b:20} + {b:30} = {a:10, b:30}, I think that +> would make sense
as an alternative to +, where the result shadows instead of snapshots the left hand side for the same effect until it changes.
Kris Kowal
The direction is wrong. It’s what I like most about <| – that it’s graphical, intuitive and indicates a direction.
Is there a list of symbols that have already been rejected? I still like <| best (better than a word such as beget or proto), followed by <~ and <:
Allen, that link brings me to the "About this wiki" page
with corrected link to wiki page: harmony:proto_operator#suggestion_to_replace_with
On Mar 2, 2012, at 2:30 PM, Allen Wirfs-Brock wrote:
It was recently suggested to me that it is unlikely that we will ever adopt -> as as function expression shorthand symbol and that this means we could consider using that symbol sequence for other purposes. In particular, it would be a reasonable and possibly less controversial alternative to the <| symbol. I would have no objection to that switch and have written the suggestion up at harmony:proto_operator#suggestion_to_replace_with
Some examples of this usage of -> include:
MyObject.prototype -> {a:1,b:2} appArrayBehavior->[0,1,2,3,4,5] let subclass = superclass -> function () {}; var p = newRegExpMethods -> /[a-m][3-7]/
What do you think? Do you like -> better than <| ? Is it ok to not have it available for some possible future function shorthand?
Thanks - This looks really nice!
Sorry, I actually meant to ask a question: Isn’t the direction of -> wrong?
What do you think? Do you like -> better than <| ? Is it ok to not have it available for some possible future function shorthand?
Both => and -> have strong associations with function shorthands from C#, Scala, C++, Java 8, Perl, CoffeeScript, ML, Haskell and more. Whether or not JavaScript adopts a ->/=> shorthand in the future (I still think it should), many developers will think of it as having an association with functions. Using -> for the proto-of operator effectively also removes the ability to use => as function shorthand later, due to the syntactic similarity of these two operators.
Luke
On Mar 2, 2012, at 4:28 PM, Axel Rauschmayer wrote:
Sorry, I actually meant to ask a question: Isn’t the direction of -> wrong?
It's a matter of opinion. UML thinks that <| points is pointing in the "right" direction (towards the more general object). However, a lot of people think about inheritance as methods flowing from/provided by the super thing to the sub thing. That perspective is more in alignment with ->
At this stage, choice of a symbol seems to be most about what will cause the lesser about of opposition based solely upon the symbol choice. Some people seem top really hate <|. If there a reasonable alternatives that don't generate the same sort of negative response then it is worth considering them.
On Mar 2, 2012, at 4:31 PM, Luke Hoban wrote:
What do you think? Do you like -> better than <| ? Is it ok to not have it available for some possible future function shorthand?
Both => and -> have strong associations with function shorthands from C#, Scala, C++, Java 8, Perl, CoffeeScript, ML, Haskell and more. Whether or not JavaScript adopts a ->/=> shorthand in the future (I still think it should), many developers will think of it as having an association with functions. Using -> for the proto-of operator effectively also removes the ability to use => as function shorthand later, due to the syntactic similarity of these two operators.
Any of these usages (at least for the more widely used languages) are fairly new so I don't know that they establish that strong of a precedent for ES.
The starting premise for considering -> is that we are not likely to use it (or =>) for a lambda shorthand. Block lambda seems to be the direction that how the most momentum.
What do you think? Do you like -> better than <| ? Is it ok to not have it available for some possible future function shorthand?
Both => and -> have strong associations with function shorthands from C#, Scala, C++, Java 8, Perl, CoffeeScript, ML, Haskell and more. Whether or not JavaScript adopts a ->/=> shorthand in the future (I still think it should), many developers will think of it as having an association with functions. Using -> for the proto-of operator effectively also removes the ability to use => as function shorthand later, due to the syntactic similarity of these two operators.
Any of these usages (at least for the more widely used languages) are fairly new so I don't know that they establish that strong of a precedent for ES.
They are new now, but 5 years from now when ES6 has breadth adoption these other languages will also be 5 years more established. Many programmers will work in at least one of these other languages as well as in JavaScript. There is also a relatively strong association of C-style languages using ->/=> as function shorthand, and JavaScript is still (for better or worse) primarily seen as a C-style language.
Luke
It's a matter of opinion. UML thinks that <| points is pointing in the "right" direction (towards the more general object).
I thought about the [[Prototype]] property pointing from the “prototypee” to the prototype. And of the way prototype (property lookup) chains go from prototypees to prototypes.
However, a lot of people think about inheritance as methods flowing from/provided by the super thing to the sub thing. That perspective is more in alignment with ->
OK, as in “prototype of”.
At this stage, choice of a symbol seems to be most about what will cause the lesser about of opposition based solely upon the symbol choice. Some people seem to really hate <|. If there a reasonable alternatives that don't generate the same sort of negative response then it is worth considering them.
Agreed. At this point, I’ll be fine with any notation, as long as we eventually have this operator. I’m normally wary of grawlixification, but this is one case where (IMO) something grawlixy works well.
So far any proposal I have seen has been met with strong opposition. How does one resolve such stalemates? Popular vote? But design by the people is usually even worse than design be committee – Fred Brooks argues that good design is best decided by a single person (two, if one of them is dominant). A TC39 vote? A BDFL decree?
I'm with Luke here. We shouldn't abuse a common idiom from other languages, including upstream ones such as CoffeeScript.
Kris's suggestion of +> changed to deal with the "wrong direction"
criticism (which I find compelling since the [[Prototype]] property is a reference):
let sub = sup +< {p:1, q:2};
(E4X ambiguity, no worries.)
Comments?
In the spirit of "derives from" (it really is more intuitive for most, though I liked <| because I already got used to UML direction), I'd throw in
==> (as in "it follows (that)")
I also wanted to add something like modus ponens character used in logic, but
|-
does not work, it already has its own meaning.
More possibilities (Alas, <* does not work, because the asterisk is not vertically centered in some fonts), in order of preference (the first one has already been suggested, but AFAIK not been rejected, yet).
let sub = sup <: {p:1, q:2}; let sub = sup <~ {p:1, q:2}; let sub = sup <> {p:1, q:2};
let sub = sup >< {p:1, q:2};
Overloading bitwise operators, which is pretty easy to determine?
var parent = { prop1: parent1 };
inherit + overrides var obj = parent | { prop1: newValue1, inherit2 : inherit2 } = { prop1: parent1, prop2: inherit2 }
inherit - overrides var diff = proto & { prop1: newValue1: prop2: value 2 } = { prop1: newValue1, prop2: val2 }
I already use constants in this way to represent complex preset objects;
var flags = [ 'PRIVAVTE', 'ENUMERABLE', 'CONFIGURABLE', 'READONLY', 'WRITABLE', 'FROZEN', 'HIDDEN', 'NORMAL', ];
var flags = { get name() return flags[this.enumerable | this.configurable << 1 | this.writable << 2] }, set name(){ this.configurable = Boolean(v & CONFIGURABLE); this.enumerable = Boolean(v & ENUMERABLE); this.writable = Boolean(v & WRITABLE); } }
On Mar 3, 2012, at 5:24 AM, Axel Rauschmayer <axel at rauschma.de> wrote:
More possibilities (Alas, <* does not work, because the asterisk is not vertically centered in some fonts), in order of preference (the first one has already been suggested, but AFAIK not been rejected, yet).
let sub = sup <: {p:1, q:2};
Yes, <: is still preferred of those that arrow left
On Sat, Mar 3, 2012 at 1:00 AM, Brendan Eich <brendan at mozilla.org> wrote:
I'm with Luke here. We shouldn't abuse a common idiom from other languages, including upstream ones such as CoffeeScript.
Kris's suggestion of +> changed to deal with the "wrong direction" criticism (which I find compelling since the [[Prototype]] property is a reference):
let sub = sup +< {p:1, q:2};
(E4X ambiguity, no worries.)
Comments?
I like, though <+ is a little easier on the eyes.
One argument for the "wrong direction" being wrong: if A <: B is common math syntax for A is a subtype of B, if you turn the arrow around it'd read A is a supertype of B, and this is fairly close to what <| was trying to express.
On Sat, Mar 3, 2012 at 6:54 AM, Dean Landolt <dean at deanlandolt.com> wrote:
One argument for the "wrong direction" being wrong: if A <: B is common math syntax for A is a subtype of B, if you turn the arrow around it'd read A is a supertype of B, and this is fairly close to what <| was trying to express.
I think the reason that we don't all instantly agree on the direction is simple: the operation is not directional. The operation is composition; the operands are not types but components of a type. Thus I think a 'natural' feeling syntax won't be arrow-ish.
Ultimately Allen is attempting to provide some of the benefit of setting proto while avoiding some of its problems. Perhaps a syntax closer its home? eg something like a set-prototypeOf property
{ ^:MyObject.prototype, a:1,b:2}
[0,1,2,3,4,5].^ = appArrayBehavior
let subclass = Function.create(superclass, {});
var p = /[a-m][3-7]/.^ = newRegExpMethods;
jjb
One argument for the "wrong direction" being wrong: if A <: B is common math syntax for A is a subtype of B, if you turn the arrow around it'd read A is a supertype of B, and this is fairly close to what <| was trying to express.
Right! Thus: If the symbol looks like an arrow then it should point from right to left:
A <| { }
A <~ { }
If it is loosely reminiscent of subset or superset then it should be “is superset of”.
A :> { }
One might also be able to reuse the super keyword from super references:
A super { }
The we might need new terminology such as "is super-object of”.
On Sat, Mar 3, 2012 at 11:08 AM, John J Barton <johnjbarton at johnjbarton.com>wrote:
On Sat, Mar 3, 2012 at 6:54 AM, Dean Landolt <dean at deanlandolt.com> wrote:
One argument for the "wrong direction" being wrong: if A <: B is common math syntax for A is a subtype of B, if you turn the arrow around it'd read A is a supertype of B, and this is fairly close to what <| was trying to express.
I think the reason that we don't all instantly agree on the direction is simple: the operation is not directional. The operation is composition; the operands are not types but components of a type. Thus I think a 'natural' feeling syntax won't be arrow-ish.
What you're describing sounds a lot more like trait composition than prototypal extension. While that'd be great it's already been nixed for this go-round. I don't really think of this op as a function composition but regardless, it's definitely a non-commutative binary operation -- there are two arguments and the order matters a great deal. We just have to decide what order. But yeah, it's pretty arbitrary, and both prior art and intuition seem a bit muddy :-/
Speaking of compositions though, I can't recall if it was ever discussed whether this operator can be chained, and if so, whether it associates. I don't see too much value in this since references to any intermediate constructions would only be available by walking the proto chain. I can't think of a great use case, just curious if it's been considered and/or rejected?
Ultimately Allen is attempting to provide some of the benefit of setting proto while avoiding some of its problems. Perhaps a syntax closer its home? eg something like a set-prototypeOf property
{ ^:MyObject.prototype, a:1,b:2}
[0,1,2,3,4,5].^ = appArrayBehavior
let subclass = Function.create(superclass, {});
var p = /[a-m][3-7]/.^ = newRegExpMethods;
This style of syntax suggests that it could be used after creation just the same, e.g.:
var p = /[a-m]-3-7]/; p.^ = newRegExpMethods;
Since setting proto may only happen at the moment of construction this would have to result in a confusing syntax error (fancy AST reductions notwithstanding). IIRC this is one reason Allen gave for the syntax he proposed.
Speaking of compositions though, I can't recall if it was ever discussed whether this operator can be chained, and if so, whether it associates. I don't see too much value in this since references to any intermediate constructions would only be available by walking the proto chain. I can't think of a great use case, just curious if it's been considered and/or rejected?
If it was chainable you could use it to do poor man’s mixins. But the requirement that the rhs be an object literal prevents chaining. Otherwise, you would have to define some kind of clone operation for intermediate lhs operands.
On Mar 3, 2012, at 8:51 AM, Dean Landolt wrote:
Speaking of compositions though, I can't recall if it was ever discussed whether this operator can be chained, and if so, whether it associates. I don't see too much value in this since references to any intermediate constructions would only be available by walking the proto chain. I can't think of a great use case, just curious if it's been considered and/or rejected?
It's left associative as part of MemberExpression and CallExpression. The the last couple ES6 spec. drafts.
OK, forget that. You could still produce left-hand sides...
On Mar 3, 2012, at 8:51 AM, Dean Landolt wrote:
What you're describing sounds a lot more like trait composition than prototypal extension. While that'd be great it's already been nixed for this go-round. I don't really think of this op as a function composition but regardless, it's definitely a non-commutative binary operation -- there are two arguments and the order matters a great deal. We just have to decide what order. But yeah, it's pretty arbitrary, and both prior art and intuition seem a bit muddy :-/
One reason that I prefer <| is that I find it easy to think about it as a close approximation to an atomic symbol such as ◁ (U+35c1). I don't perceive the < and | as individual elements and hence I don't have any cognitive dissonance about its meaning. I find this less so with +< which places + in a more distinctive position which leads me to think about mean of + in this new context. I have a similar, but slightly less negative reaction to <~ simply because the ~ is much more visually distinct than | . I admit that this distinction between <| and <~ or +< seems pretty arbitrary, but at least for me, I think it has an actual perceptual basis.
On Sat, 03 Mar 2012 01:55:59 +0100, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
At this stage, choice of a symbol seems to be most about what will cause
the lesser about of opposition based solely upon the symbol choice.
Some people seem top really hate <|. If there a reasonable alternatives
that don't generate the same sort of negative response then it is worth
considering them.
Since it seems there are many supporters for "arrow-like" symbols pointing in either direction, and both of these groups seem to think the symbol points in the "wrong" direction if it isn't the direction they imagine it pointing to, perhaps it's better to look for more alternatives of direction-neutral operators instead. Here are some suggestions:
let obj = proto \\ {
prop: "test",
foo: 10
}
let obj = proto #: {
prop: "test",
foo: 10
}
Another "direction-neutral" symbol that has been proposed is <>. I think
operators without a sense of direction would see less opposition.
Jonas
(This is my first post to the list; I couldn't find anything that indicates that input from members of the ECMAScript community is unwanted. If I'm not supposed to participate, just tell me and I'll be quiet.)
On Sat, 03 Mar 2012 19:45:48 +0100, Jonas Höglund <firefly at firefly.nu>
wrote: [...]
Eek, sorry about the spam. My mail client wasn't properly set up.
Jonas
Jonas Höglund wrote:
Since it seems there are many supporters for "arrow-like" symbols pointing in either direction, and both of these groups seem to think the symbol points in the "wrong" direction if it isn't the direction they imagine it pointing to, perhaps it's better to look for more alternatives of direction-neutral operators instead. Here are some suggestions:
let obj = proto \ { prop: "test", foo: 10 } let obj = proto #: { prop: "test", foo: 10 }
As for the nondirectional ones, does this collide with something?
let obj = proto ^^ { prop: "test", foo: 10 }
I find the syntax `proto -> object' counter-intuitive. Anytime I think
about prototype delegation,
the semantics are clear that an object X' delegates to a prototypeY'.
This semantics don't map
well in `proto -> object', instead you have something more along the
lines proto is the basis of object', although the first thing that comes to mind is stillproto
maps to object'.
And yes, this is a nitpick.
On the other hand, there are strong associations of such a symbol with different semantics in other languages, property access and function shorthands being the most common. I'm not sure introducing a symbol that's been used for entirely different semantics in the majority of other languages is a good idea, and would bring more confusion.
<- sounds too much like return (local or not).
So, at this point I still think lhs <| rhs' is the best alternative in syntax, as it lends itself easily to therhs delegates to lhs', which is the core semantics of a delegative
prototype implementation.
I find the syntax `proto -> object' counter-intuitive. Anytime I think
about prototype delegation,
the semantics are clear that an object X' delegates to a prototypeY'.
This semantics don't map
well in `proto -> object', instead you have something more along the
lines proto is the basis of object', although the first thing that comes to mind is stillproto
maps to object'.
And yes, this is a nitpick.
On the other hand, there are strong associations of such a symbol with different semantics in other languages, property access and function shorthands being the most common. I'm not sure introducing a symbol that's been used for entirely different semantics in the majority of other languages is a good idea, and would bring more confusion.
<- sounds too much like return (local or not).
So, at this point I still think lhs <| rhs' is the best alternative in syntax, as it lends itself easily to therhs delegates to lhs', which is the core semantics of a delegative
prototype implementation.
On Mar 3, 2012, at 3:26 PM, Herby Vojčík <herby at mailbox.sk> wrote:
Jonas Höglund wrote:
Since it seems there are many supporters for "arrow-like" symbols pointing in either direction, and both of these groups seem to think the symbol points in the "wrong" direction if it isn't the direction they imagine it pointing to, perhaps it's better to look for more alternatives of direction-neutral operators instead. Here are some suggestions:
let obj = proto \ { prop: "test", foo: 10 } let obj = proto #: { prop: "test", foo: 10 }
As for the nondirectional ones, does this collide with something?
let obj = proto ^^ { prop: "test", foo: 10 }
This is exceptionally jarring to look at
On Mar 3, 2012, at 2:24 AM, Axel Rauschmayer wrote:
let sub = sup <: {p:1, q:2};
This one has been one my least-objectionable options.
let sub = sup <~ {p:1, q:2};
Doesn't work; ~ is a unary operator.
let sub = sup <> {p:1, q:2};
Has a pretty strong "not equal to" connotation.
let sub = sup >< {p:1, q:2};
This just looks random.
On Mar 3, 2012, at 6:54 AM, Dean Landolt wrote:
I like, though <+ is a little easier on the eyes.
Ambiguous. + is a unary operator.
One argument for the "wrong direction" being wrong: if A <: B is common math syntax for A is a subtype of B, if you turn the arrow around it'd read A is a supertype of B, and this is fairly close to what <| was trying to express.
Yeah, that's one of the things I don't like about <:.
On Mar 3, 2012, at 1:28 PM, Quildreen Motta wrote:
<- sounds too much like return (local or not).
And it's ambiguous. - is a unary operator.
On Mar 2, 2012, at 2:30 PM, Allen Wirfs-Brock wrote:
What do you think? Do you like -> better than <| ?
I like -> much, much better than <|. The latter looks like we ran out of options but desperately wanted to shoe-horn something into an already heavily constrained syntax. Which, of course, is exactly what we are doing. ;-)
But -> is a familiar and accepted ASCIIfication of an arrow. Given that the prototype relationship is directional (contra JJB's claim, which I didn't understand), it's natural to use an arrow. I understand that there are reasons to prefer the other direction, but sadly that's not an option due to the ambiguity of <-.
All other options I've seen so far just look desperate.
Is it ok to not have it available for some possible future function shorthand?
IMO, yes.
On Mar 2, 2012, at 4:31 PM, Luke Hoban wrote:
What do you think? Do you like -> better than <| ? Is it ok to not have it available for some possible future function shorthand?
Both => and -> have strong associations with function shorthands from C#, Scala, C++, Java 8, Perl, CoffeeScript, ML, Haskell and more.
This argument seems to over-reach. C and C++ use -> for pointer indirection. Perl uses -> for method calls.
Whether or not JavaScript adopts a ->/=> shorthand in the future (I still think it should), many developers will think of it as having an association with functions.
I don't know. If we want to use it for function shorthand, that's one thing. But every language defines its own syntax. And arrows are a very generic notation in CS, used for many, many more things than functions.
Using -> for the proto-of operator effectively also removes the ability to use => as function shorthand later, due to the syntactic similarity of these two operators.
This is definitely true. We have only got so much grawlix space left in the universe to use. Meanwhile, JavaScript has functions, and JavaScript has prototypes. We're going to have to make some decisions.
+1 for -> syntax.
El 03/03/2012, a las 21:26, Herby Vojčík escribió:
If we’re taking votes:
-1. I would actively avoid using this in my own ES6 code, because of the unnecessary confusion it would cause to those coming from CoffeeScript.
From: Carlos Prado García Sent: Saturday, March 03, 2012 17:58:38 To: es-discuss Subject: Re: How about replacing <| with ->
+1 for -> syntax.
On Sat, Mar 3, 2012 at 5:20 PM, David Herman <dherman at mozilla.com> wrote:
On Mar 2, 2012, at 4:31 PM, Luke Hoban wrote:
What do you think? Do you like -> better than <| ? Is it ok to not have it available for some possible future function shorthand?
Both => and -> have strong associations with function shorthands from C#, Scala, C++, Java 8, Perl, CoffeeScript, ML, Haskell and more.
This argument seems to over-reach. C and C++ use -> for pointer indirection. Perl uses -> for method calls.
This is precisely why it can't really be overloaded any further.
Whether or not JavaScript adopts a ->/=> shorthand in the future (I still think it should), many developers will think of it as having an association with functions.
I don't know. If we want to use it for function shorthand, that's one thing. But every language defines its own syntax. And arrows are a very generic notation in CS, used for many, many more things than functions.
Using -> for the proto-of operator effectively also removes the ability to use => as function shorthand later, due to the syntactic similarity of these two operators.
This is definitely true. We have only got so much grawlix space left in the universe to use.
Does it have to be ascii? The growlix space of unicode is vast: plus.google.com/109925364564856140495/posts
Reaching into the depths of unicode was roundly panned during the function shorthand debates but Allen's reach for ◁ is compelling -- is it really so bad to just go all in for it?
FWIW I personally think <| is just fine :)
On Mar 3, 2012, at 3:24 PM, Dean Landolt wrote:
On Sat, Mar 3, 2012 at 5:20 PM, David Herman <dherman at mozilla.com> wrote: This argument seems to over-reach. C and C++ use -> for pointer indirection. Perl uses -> for method calls.
This is precisely why it can't really be overloaded any further.
It's not "overloading" when different languages use a symbol for different purposes. They're different languages-- they are by definition different notational systems! There's not some global registry of ASCII art where each language stakes a permanent claim to a universal meaning for a given symbol.
There's tons of precedent for -> to be visually interpreted as an arrow and for arrows to be used for different purposes. That there is variety across languages is evidence of the flexibility of the symbol, not of its being closed off to repurposing.
Does it have to be ascii? The growlix space of unicode is vast: plus.google.com/109925364564856140495/posts
Reaching into the depths of unicode was roundly panned during the function shorthand debates but Allen's reach for ◁ is compelling -- is it really so bad to just go all in for it?
Yes. There are so many points in the pipeline, from programmer to server to router to browser, where encoding bugs can crop up. And anyway the point is not to make it look like an exotic alien glyph in the middle of a program. :)
FWIW I personally think <| is just fine :)
All I can say is it looks terrible. I don't have any way to quantify that, of course.
On Mar 2, 2012, at 4:31 PM, Luke Hoban wrote:
What do you think? Do you like -> better than <| ? Is it ok to not have it available for some possible future function shorthand?
Using -> for the proto-of operator effectively also removes the ability to use => as function shorthand later, due to the syntactic similarity of these two operators.
On second thought, that's actually not true. The fact that CoffeeScript uses both for functions (with different this-binding) behavior is actually not universally loved; it causes confusion due to the extremely close similarity of the operations. By contrast, using the two symbols for very different purposes means that you don't get subtle changes in your program's behavior if you get the wrong one-- it fails faster. It's not at all a foregone conclusion that we couldn't use => for a function form and -> for proto.
2012/3/3 Domenic Denicola <domenic at domenicdenicola.com>
If we’re taking votes:
-1. I would actively avoid using this in my own ES6 code, because of the unnecessary confusion it would cause to those coming from CoffeeScript.
Why should ES/JavaScript make its decisions based on a transpiled language that actually requires JS itself to exist? I don't think it should matter either way...
On Sat, Mar 3, 2012 at 7:37 PM, David Herman <dherman at mozilla.com> wrote:
On Mar 3, 2012, at 3:24 PM, Dean Landolt wrote:
On Sat, Mar 3, 2012 at 5:20 PM, David Herman <dherman at mozilla.com> wrote:
This argument seems to over-reach. C and C++ use -> for pointer indirection. Perl uses -> for method calls.
This is precisely why it can't really be overloaded any further.
It's not "overloading" when different languages use a symbol for different purposes. They're different languages-- they are by definition different notational systems! There's not some global registry of ASCII art where each language stakes a permanent claim to a universal meaning for a given symbol.
There's tons of precedent for -> to be visually interpreted as an arrow and for arrows to be used for different purposes. That there is variety across languages is evidence of the flexibility of the symbol, not of its being closed off to repurposing.
Does it have to be ascii? The growlix space of unicode is vast: plus.google.com/109925364564856140495/posts
Reaching into the depths of unicode was roundly panned during the function shorthand debates but Allen's reach for ◁ is compelling -- is it really so bad to just go all in for it?
Yes. There are so many points in the pipeline, from programmer to server to router to browser, where encoding bugs can crop up. And anyway the point is not to make it look like an exotic alien glyph in the middle of a program. :)
FWIW I personally think <| is just fine :)
All I can say is it looks terrible. I don't have any way to quantify that, of course.
I will gladly do a survey of the web development community to satisfy any requests for qualification. I also think it looks terrible - because it does. The concept is tremendously awesome, the representation is unfortunate.
On Mar 3, 2012, at 5:39 PM, Rick Waldron wrote:
All I can say is it looks terrible. I don't have any way to quantify that, of course.
I will gladly do a survey of the web development community to satisfy any requests for qualification.
More information is always welcome. It's always interesting to hear what people think. That said, it would be hard to get an unbiased sample.
On Sat, Mar 3, 2012 at 8:52 PM, David Herman <dherman at mozilla.com> wrote:
On Mar 3, 2012, at 5:39 PM, Rick Waldron wrote:
All I can say is it looks terrible. I don't have any way to quantify that,
of course.
I will gladly do a survey of the web development community to satisfy any requests for qualification.
More information is always welcome. It's always interesting to hear what people think. That said, it would be hard to get an unbiased sample.
I've done a handful of surveys and just let twitter carry it - the results are almost always surprising (vs. what I've expected them to be)
-1. I would actively avoid using this in my own ES6 code, because of the unnecessary confusion it would cause to those coming from CoffeeScript.
Why should ES/JavaScript make its decisions based on a transpiled language that actually requires JS itself to exist? I don't think it should matter either way...
Because the overlap between CoffeeScript programmers and JavaScript programmers is one of the highest between JavaScript and any other language. And this overlap will only increase by the time ES6 makes it out the door.
If you're arguing that CoffeeScript should change itself to accommodate JavaScript, well, maybe Jeremy can comment on how likely that is. Personally I think es-discuss should be careful not to alienate such a large and growing fraction of their userbase, especially with comments like the above that seem, on the surface at least, to be belittling the role and importance of CoffeeScript. IMO "CoffeeScript 6" will be a very important factor in the success of ECMAScript 6, so making it as easy and welcoming as possible is an important consideration.
2012/3/3 Domenic Denicola <domenic at domenicdenicola.com>
-1. I would actively avoid using this in my own ES6 code, because of the unnecessary confusion it would cause to those coming from CoffeeScript.
Why should ES/JavaScript make its decisions based on a transpiled language that actually requires JS itself to exist? I don't think it should matter either way...
Because the overlap between CoffeeScript programmers and JavaScript programmers is one of the highest between JavaScript and any other language. And this overlap will only increase by the time ES6 makes it out the door.
If you're arguing that CoffeeScript should change itself to accommodate JavaScript, well, maybe Jeremy can comment on how likely that is. Personally I think es-discuss should be careful not to alienate such a large and growing fraction of their userbase, especially with comments like the above that seem, on the surface at least, to be belittling the role and importance of CoffeeScript. IMO "CoffeeScript 6" will be a very important factor in the success of ECMAScript 6, so making it as easy and welcoming as possible is an important consideration.
Pure strawman.
David Herman summarized my feeling about it best here:
"...different languages use a symbol for different purposes. They're different languages-- they are by definition different notational systems! "
When Jeremy was developing CoffeeScript, he clearly didn't say "JavaScript may someday want to use ->, so I better not use it" and why should he? It's
a different language, with many different notations.
None of the syntax options presented so far seem to be winning. Would not specifying the prototype somewhere inside of the object literal also be an option? If so, would anyone like to take a crack at that?
khs
On Mar 3, 2012, at 8:00 PM, Kevin Smith wrote:
None of the syntax options presented so far seem to be winning. Would not specifying the prototype somewhere inside of the object literal also be an option? If so, would anyone like to take a crack at that?
We already explored that path (trace back the history of the object literal proposals on the wiki). The <| semantics needs to also work with at least function expressions and array literals.. In the future it probably needs to be extensible to block lambda. Some thing that is "outside" is more flexible in accommodating various syntactic forms.
Dean Landolt wrote:
Does it /have/ to be ascii?
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
a while back, and we discussed alternative contextual keywords. Grawlix appears to result in (a) strong anti-grawlix reaction from a good part of the community; (b) no consensus on which cuss-characters to use.
I think it's worse to have combined characters, like #@ or ^& than it is to have same character repeated... ^^ looks nice to me (also points up, which may create a little analogy to the UML generalization), but ok. Two same characters are more easily spotted, imho, and they are more easily typed.
These may also be the options:
let obj = proto ** {
prop: "test",
foo: 10
}
let obj = proto <<< {
prop: "test",
foo: 10
}
(others are not usable, they look jarring even to me: !!, %%, ##, @@)
<<< looks like a bitwise operator and if ** was to be an operator, I'd prefer it to be a shorhand for Math.pow.
Sent from my smartphone.
On Mar 4, 2012, at 2:17 AM, Brendan Eich <brendan at mozilla.org> wrote:
Dean Landolt wrote:
Does it /have/ to be ascii?
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
a while back, and we discussed alternative contextual keywords. Grawlix appears to result in (a) strong anti-grawlix reaction from a good part of the community; (b) no consensus on which cuss-characters to use.
I think this feels the least alien to me. I keep wanting a operator to do the trick, but I am finding that nothing does. 'beget' is ok, but it still feel a little forced. What is this, the bible?
While we're all throwing our hats in the ring, I will renew my proposal for extends as a binary prefix operator.
let sub = extends sup {p:1, q:2, r:3};
And I would additionally advocate for a form that combines with declarations
let sub extends sup {p:1, q:2, r:3}; function Sub(x,y) extends Sup { super(x); this.y = y; }
This would hopefully jive really well with whatever class proposal gets decided on, now or later.
On Sat, Mar 3, 2012 at 11:17 PM, Brendan Eich <brendan at mozilla.org> wrote:
Dean Landolt wrote:
Does it /have/ to be ascii?
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
The problem with <| and friends is that the common mental association with these symbols do not describe the operation. That is also true for 'beget'. |sup| begets |sub|, not {p:1, q:2, r:3};
The operator needs to be mentally associated with the formation of a compound object from parts: let sub = sup joins {p:1, q:2, r:3}; let sub = sup backs {p:1, q:2, r:3}; // as in table-lookup let sub = sub with {p:1, q:2, r:3}; // I heard this one was unemployed let sub = sup injected-into {p:1, q:2, r:3}; If we agreed to call the operator something like "injected-into", then suddenly the arrow starts to make sense.
jjb
a while back, and we discussed alternative contextual keywords. Grawlix appears to result in (a) strong anti-grawlix reaction from a good part of the community; (b) no consensus on which cuss-characters to use.
I'm not a fan of funky syntax, but I think a bigger problem in this particular case is our inability to articulate the operation being discussed in a short phrase. Recall we discussed this before and tried out "setPrototypeOf" etc. Nothing stuck. That's why the cuss words are easy ;-)
On Mar 3, 2012, at 11:17 PM, Brendan Eich wrote:
Dean Landolt wrote:
Does it /have/ to be ascii?
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
a while back, and we discussed alternative contextual keywords. Grawlix appears to result in (a) strong anti-grawlix reaction from a good part of the community; (b) no consensus on which cuss-characters to use.
I have two significant sized code samples that differ only in the use of "beget" in place of <|
Compare:
allenwb/ESnext-experiments/blob/master/ST80collections-exp1.js
and
allenwb/ESnext-experiments/blob/master/ST80collections-exp6.js
John J Barton wrote:
On Sat, Mar 3, 2012 at 11:17 PM, Brendan Eich<brendan at mozilla.org> wrote:
Dean Landolt wrote:
Does it /have/ to be ascii?
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
The problem with<| and friends is that the common mental association with these symbols do not describe the operation. That is also true for 'beget'. |sup| begets |sub|, not {p:1, q:2, r:3};
The operator needs to be mentally associated with the formation of a compound object from parts: let sub = sup joins {p:1, q:2, r:3}; let sub = sup backs {p:1, q:2, r:3}; // as in table-lookup let sub = sub with {p:1, q:2, r:3}; // I heard this one was unemployed let sub = sup injected-into {p:1, q:2, r:3}; If we agreed to call the operator something like "injected-into", then suddenly the arrow starts to make sense.
jjb
a while back, and we discussed alternative contextual keywords. Grawlix appears to result in (a) strong anti-grawlix reaction from a good part of the community; (b) no consensus on which cuss-characters to use.
I'm not a fan of funky syntax, but I think a bigger problem in this particular case is our inability to articulate the operation being discussed in a short phrase. Recall we discussed this before and tried out "setPrototypeOf" etc. Nothing stuck. That's why the cuss words are easy ;-)
I've got no problem to see what operation it is, "create derived (eg. ancestor) entity".
So from above proposal, only "backs" seems like having good meaning. I'd say:
let sub = sup derived {p:1, q:2, r:3};
Herby
P.S.: Maybe even let sub = sup offspring {p:1, q:2, r:3};
P.P.S.: I don't know what 'beget' means (I know I can find it, just to illustrate it's not a commonly known word).
On Mar 4, 2012, at 9:18 AM, Herby Vojčík wrote:
P.P.S.: I don't know what 'beget' means (I know I can find it, just to illustrate it's not a commonly known word).
I've had a concern about the possible impact of keyword choice on non-native English speakers who are trying to learn or use the language. Presumably, that is (or will be) the majority of ES developers.
Being a native English speaker, I don't have any direct experience with this (for ES ior other PLs). But we do have non-native speakers on this list and specific feed back from them would be interesting. However, I suspect that the non-native English followers of this list are probably, on average, much more fluent than the average non-natiive English web/Es developer.
If you don't know the word, is it easier to learn a new symbol (eg <|) or a new keyword (eg beget)? Long term, does it make any cognitive difference?
On Sun, Mar 4, 2012 at 9:30 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
On Mar 4, 2012, at 9:18 AM, Herby Vojčík wrote:
P.P.S.: I don't know what 'beget' means (I know I can find it, just to illustrate it's not a commonly known word).
I've had a concern about the possible impact of keyword choice on non-native English speakers who are trying to learn or use the language. Presumably, that is (or will be) the majority of ES developers.
Being a native English speaker, I don't have any direct experience with this (for ES ior other PLs). But we do have non-native speakers on this list and specific feed back from them would be interesting. However, I suspect that the non-native English followers of this list are probably, on average, much more fluent than the average non-natiive English web/Es developer.
If you don't know the word, is it easier to learn a new symbol (eg <|) or a new keyword (eg beget)? Long term, does it make any cognitive difference?
As a native English speaker, even though I happen to know the word "beget", it's still quite strange. I would be confused when I first saw it. I prefer either a word that's closer to ES (like "protoFor" or something), or a symbol.
I'm not a native english speaker and I think both are the same when learning.
Words allow people not knowing JS to kind of understand. Symbols are shorter to write and are easier to spot when looking at code.
I'd prefer a symbol but I'm sure others would prefer a word (that's why some operators became words in cofeescript).
So either we want all codes to look alike and we chose one of those two options, or we want to let people chose and we add a word and a symbol.
Sent from my smartphone.
Allen Wirfs-Brock wrote:
On Mar 4, 2012, at 9:18 AM, Herby Vojčík wrote:
P.P.S.: I don't know what 'beget' means (I know I can find it, just to illustrate it's not a commonly known word).
If you don't know the word, is it easier to learn a new symbol (eg <|) or a new keyword (eg beget)? Long term, does it make any cognitive difference?
If I don't know the word, the symbol is easier, but once I know the word (which is matter of googling or including the explanation), it is the same. There are some operator-words already (instanceof) which cause no problem, when one knows their meaning.
The first time I saw the "<|" symbol I found it frightening and thought that developpers would find it frightening too.
But it is easy to get used to it if we just think about the visual representation and it looks more friendly than other proposals along this post.
I don't like a lot "->", it can look more friendly at first step, but
can be confusing with other languages's use (makes me think to damn php stuff)
So I prefer "<|"
Le 03/03/2012 18:35, Allen Wirfs-Brock a écrit :
On Mar 3, 2012, at 11:17 PM, Brendan Eich wrote:
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
+1. Using a symbol like an arrow makes a lot of sense when there is a clear directionality in the operation (e.g. chasing a chain of pointers in C), but the lack of consensus as to which direction the arrow should point in seems likely to be indicative of a larger problem - that either choice is going to be backwards, unintuitive, and confusing for a significant proportion the users.
On Mar 4, 2012, at 9:18 AM, Herby Vojčík wrote:
P.S.: Maybe even let sub = sup offspring {p:1, q:2, r:3};
P.P.S.: I don't know what 'beget' means (I know I can find it, just to illustrate it's not a commonly known word).
Apologies in advance for using a four letter word, but the following is simple, a common word, is becoming available, and reads well to me:
let sub = sup with {p:1, q:2, r:3};
I worry mainly about terminology. Wouldn’t “beget” introduce a new term for specifying “the prototype of”? Learning a new word in and of itself has never been a problem for me, especially when it goes along with a new concept.
More possibilities (I know some of these have been suggested before, I searched the archives, but couldn’t find whether they had been rejected):
A super { ... }
“A is super-object of { ... }”
A proto { ... }
“A is prototype of { ... }”
A with { ... }
“A with instance { ... }”
A has { ... }
“A has instance { ... }”
A subsumes { ... }
“A subsumes { ... }”On 03/04/2012 02:14 PM, Allen Wirfs-Brock wrote:
On Mar 3, 2012, at 11:17 PM, Brendan Eich wrote:
Dean Landolt wrote:
Does it /have/ to be ascii?
Does it have to be grawlix? [snip...]
I have two significant sized code samples that differ only in the use of "beget" in place of <|
Compare:
allenwb/ESnext-experiments/blob/master/ST80collections-exp1.js
and
allenwb/ESnext-experiments/blob/master/ST80collections-exp6.js
Allen
es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss
My major problem with a spelt out operator is that it gets difficult to tell it from the surrounding words at a glance. Though it gets a little better if one has some sort of syntax highlighting support, the symbols are just easier to spot in the code, which gives you the ability to just glance at related pieces of code (for those who abuse editors like Emacs for side-by-side views of the code, like me) and tell the relationships between those objects.
It's just that with a spelt out operator you actually have to read the whole line.
About the choice of a word operator vs a symbol operator based on whether the programmers are native English speaker or not, I don't think it would make much of a difference. I did have my concerns at first as well, but I haven't felt any additional cognitive load to remember either, so I think they both impose about the same amount of additional learning for a programmer that is unfamiliar with the additions in Harmony.
On 03/04/2012 03:38 PM, Gavin Barraclough wrote:
On Mar 3, 2012, at 11:17 PM, Brendan Eich wrote:
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
+1. Using a symbol like an arrow makes a lot of sense when there is a clear directionality in the operation (e.g. chasing a chain of pointers in C), but the lack of consensus as to which direction the arrow should point in seems likely to be indicative of a larger problem - that either choice is going to be backwards, unintuitive, and confusing for a significant proportion the users.
The operation of prototypical inheritance, as implemented by JavaScript, has a clear direction, though. It's just a delegation from an object to a prototype, thus: `super <| (or <:, or <~, or ...) { p: 1, q: 2, r: 3 }' makes sense.
With `super -> { p:1, q: 2, r: 3 }', it could be argued that the
operation as "super is the delegation for the object", although I find it slightly counter intuitive, since property lookup starts at the base object and goes all the way up to the prototype chain (as an arrow pointing to the left would suggest).
Experiment: I’ve written down the proposals that have been made so far, to reduce the circles we are going in. Let me know of any corrections or additions I should make.
docs.google.com/spreadsheet/ccc?key=0Apu8J_NsHwGGdHRtTThMZWdocy1ad2ZCaktpVVdPWEE
On Mar 3, 2012, at 3:24 PM, Dean Landolt wrote:
... Does it have to be ascii? The growlix space of unicode is vast: plus.google.com/109925364564856140495/posts
Reaching into the depths of unicode was roundly panned during the function shorthand debates but Allen's reach for ◁ is compelling -- is it really so bad to just go all in for it?
FWIW I personally think <| is just fine :)
We've never gotten any traction with adopting non-ascii syntactic characters and for good reasons.
However, we generally have looked at then as exclusive alternative. I wonder if we could get any better traction if we approached them strictly as an optional alternative. In this case we could have the more readable form ◁ (U+35c1) and the more type-able alternative <| (two ascii characters). The developer make the choice. In some fonts there is a significant visual difference.
◁ <| (courier new)
On Sun, 04 Mar 2012 20:36:31 +0100, Axel Rauschmayer <axel at rauschma.de>
wrote:
Experiment: I’ve written down the proposals that have been made so far,
to reduce the circles we are going in. Let me know of any corrections or
additions I should make.docs.google.com/spreadsheet/ccc?key=0Apu8J_NsHwGGdHRtTThMZWdocy1ad2ZCaktpVVdPWEE
You could add the "non-directional" operators I proposed, i.e. A \\ {...}
and A #: {...}. This sidesteps both the issue of having the operator
point in a direction, and of named operators being harder to notice at a
glance.
Jonas
This list is really useful!
One more to add:
<:
... has also been proposed
Allen,
On Sun, Mar 4, 2012 at 12:14 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
On Mar 3, 2012, at 11:17 PM, Brendan Eich wrote:
Dean Landolt wrote:
Does it /have/ to be ascii?
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
a while back, and we discussed alternative contextual keywords. Grawlix appears to result in (a) strong anti-grawlix reaction from a good part of the community; (b) no consensus on which cuss-characters to use.
I have two significant sized code samples that differ only in the use of "beget" in place of <|
Compare:
allenwb/ESnext-experiments/blob/master/ST80collections-exp1.js
and
allenwb/ESnext-experiments/blob/master/ST80collections-exp6.js
These are extremely helpful - thank you for sharing. It's very clear to me that a symbol/operator is the obvious choice when faced with a large code example - "beget" just gets lost, where <| is very noticeable and very obvious (and even helped me to better understand the outcome of using the operator)
Unfortunately, the examples do nothing to make me like this particular choice... but I do love seeing this language feature come to life :)
A friend commented, all the symbol forms are difficult to speak over a phone. The operator will need a common pronounceable name, so why not use that instead of a symbol.
On Sun, Mar 4, 2012 at 4:57 PM, felix <felix8a at gmail.com> wrote:
A friend commented, all the symbol forms are difficult to speak over a phone. The operator will need a common pronounceable name, so why not use that instead of a symbol.
The very first paragraph addresses this: "prototype for"
that or "prototypeof"?
"prototype for" is also referred to as:
- prototype operator
- proto operator
On 3 March 2012 02:06, Luke Hoban <lukeh at microsoft.com> wrote:
What do you think? Do you like -> better than <| ? Is it ok to not have it available for some possible future function shorthand?
Both => and -> have strong associations with function shorthands from C#, Scala, C++, Java 8, Perl, CoffeeScript, ML, Haskell and more. Whether or not JavaScript adopts a ->/=> shorthand in the future (I still think it should), many developers will think of it as having an association with functions. Using -> for the proto-of operator effectively also removes the ability to use => as function shorthand later, due to the syntactic similarity of these two operators.
Any of these usages (at least for the more widely used languages) are fairly new so I don't know that they establish that strong of a precedent for ES.
They are new now, but 5 years from now when ES6 has breadth adoption these other languages will also be 5 years more established. Many programmers will work in at least one of these other languages as well as in JavaScript. There is also a relatively strong association of C-style languages using ->/=> as function shorthand, and JavaScript is still (for better or worse) primarily seen as a C-style language.
I have to agree with Luke here.
Tiny bit of pedantry: using arrows for functions is not new at all, it has been fairly common for functional languages for at least twice as long as the total age of JavaScript. The only more recent news is that it has also trickled into the mainstream over the last decade.
On 3 March 2012 23:20, David Herman <dherman at mozilla.com> wrote:
On Mar 2, 2012, at 4:31 PM, Luke Hoban wrote:
What do you think? Do you like -> better than <| ? Is it ok to not have it available for some possible future function shorthand?
Both => and -> have strong associations with function shorthands from C#, Scala, C++, Java 8, Perl, CoffeeScript, ML, Haskell and more.
This argument seems to over-reach. C and C++ use -> for pointer indirection. Perl uses -> for method calls.
C++11 uses it for function types:
On 1 March 2012 19:34, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
What do you think? Do you like -> better than <| ? Is it ok to not have it available for functions?
I am always reticent to re-use lexical features of one language when implementing in another with wildly different semantics. Like it or not, programmers see JavaScript as a C-like language where -> generally means 'accessor', as in C++.
One could make the point that they should read the fine manual, but var scope is still a regular source of confusion: the vast majority of programmers just don't read anything more detailed than snippets on stackoverflow. I think an entirely new symbol will force them to read about the functionality and keep them from guessing about what it does.
(wow I don't know where these stale message came from....please ignore)
It was recently suggest to me that it is unlikely that we will ever adopt -> as as function expression shorthand symbol and that this means we could consider using that symbol sequence for other purposes. In particular, it would be a reasonable and possibly less controversial alternative to the <| symbol. I would have no objection to that switch and have written the suggestion up at doku.php#suggestion_to_replace_with
Some examples of this usage of -> include:
MyObject.prototype -> {a:1,b:2} appArrayBehavior->[0,1,2,3,4,5] let subclass = superclass -> function () {}; var p = newRegExpMethods -> /[a-m][3-7]/
What do you think? Do you like -> better than <| ? Is it ok to not have it available for functions?
It was recently suggest to me that it is unlikely that we will ever adopt -> as as function expression shorthand symbol and that this means we could consider using that symbol sequence for other purposes. In particular, it would be a reasonable and possibly less controversial alternative to the <| symbol. I would have no objection to that switch and have written the suggestion up at http://wiki.ecmascript.org/doku.php#suggestion_to_replace_with Some examples of this usage of -> include: MyObject.prototype -> {a:1,b:2} appArrayBehavior->[0,1,2,3,4,5] let subclass = superclass -> function () {}; var p = newRegExpMethods -> /[a-m][3-7]/ What do you think? Do you like -> better than <| ? Is it ok to not have it available for functions? Allen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120301/b42eb3d5/attachment.html>