ES6 draft, Rev20 is now available

2013-10-29 Thread Allen Wirfs-Brock
At: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts The HtML version isn't ready yet, but should be available soon. Changes include: Introduced grammar parameters and eliminated NoIn productions Spread now requires an Iterable rather than an array-like B.1.4, Web browser exte

Math.sign vs ±0

2013-10-29 Thread Oliver Hunt
As currently specified Math.sign has 5 different return values and, as far as i can tell, does not solve the problem I thought it was trying to address. That is the difficulty in distinguishing positive and negative numbers without having to manually do the divide -> ±Infinity cruft. What is th

Re: Novel operator syntax

2013-10-29 Thread Tab Atkins Jr.
On Tue, Oct 29, 2013 at 4:51 PM, Tristan Zajonc wrote: > Both operators and element-wise operators really benefit from Brendan's > multiple dispatch proposal. Julia has used this approach to great effect. > I'm not opposed to it, but I don't believe there's a compelling need for > arbitrary infix

Re: Novel operator syntax

2013-10-29 Thread Tristan Zajonc
On Tue, Oct 29, 2013 at 3:03 PM, Brendan Eich wrote: > Axel Rauschmayer wrote: > >> I would love to have a way to write function calls infix. That may cover >> your use case as well. That is (strawman syntax): >> >> arg1 #func arg2 >> >> would be syntactic sugar for >> >>func(arg1, arg2)

Re: Novel operator syntax

2013-10-29 Thread Brendan Eich
Brendan Eich wrote: Tristan Zajonc wrote: What about +:? This actually has some visual appeal if primary motivation is elementwise operations and is a syntax error with that ASI example. The downside is that it can end up pretty close to existing syntax like {a+:1} vs. {a:+1}, although I don

Re: Changes to Object.observe based on feedback from the September discussion

2013-10-29 Thread Rafael Weinstein
Note that these proposed changes are now reflected in the Object.observe spec text: http://wiki.ecmascript.org/doku.php?id=harmony:observe On Thu, Oct 17, 2013 at 3:09 PM, Rafael Weinstein wrote: > At the September meeting, the committee discussed Object.observe. Below is > a summary of the fee

Re: Novel operator syntax

2013-10-29 Thread Brendan Eich
Axel Rauschmayer wrote: I would love to have a way to write function calls infix. That may cover your use case as well. That is (strawman syntax): arg1 #func arg2 would be syntactic sugar for func(arg1, arg2) Advantages: more versatile, less grawlixy. # is pure grawlix. It's also on

Re: Novel operator syntax

2013-10-29 Thread Axel Rauschmayer
I would love to have a way to write function calls infix. That may cover your use case as well. That is (strawman syntax): arg1 #func arg2 would be syntactic sugar for func(arg1, arg2) Advantages: more versatile, less grawlixy. Problem: would make much more sense with multiple dispatch

Re: Novel operator syntax

2013-10-29 Thread Brendan Eich
Tristan Zajonc wrote: What about +:? This actually has some visual appeal if primary motivation is elementwise operations and is a syntax error with that ASI example. The downside is that it can end up pretty close to existing syntax like {a+:1} vs. {a:+1}, although I don't expect that to be

Re: Novel operator syntax

2013-10-29 Thread Tristan Zajonc
What about +:? This actually has some visual appeal if primary motivation is elementwise operations and is a syntax error with that ASI example. The downside is that it can end up pretty close to existing syntax like {a+:1} vs. {a:+1}, although I don't expect that to be a common use. On Tue, Oc

Re: Novel operator syntax

2013-10-29 Thread Brendan Eich
André Bargull wrote: There are the usual ASI problems. For example this is currently valid: ``` a ~+ b ``` It is parsed as: ``` a; ~+ b; ``` The fix we entertained for 'is' and 'isnt' was restricted productions: AdditiveExpression [no LineTerminator here] '~+' MultiplicativeExpression But

Re: Novel operator syntax

2013-10-29 Thread André Bargull
On 10/29/2013 7:51 PM, Tristan Zajonc wrote: Right you are. That was the same issue with Python. Are there any blockers to ~*? There are the usual ASI problems. For example this is currently valid: ``` a ~+ b ``` It is parsed as: ``` a; ~+ b; ``` On Tue, Oct 29, 2013 at 11:46 AM, André B

Re: Novel operator syntax

2013-10-29 Thread Brendan Eich
André Bargull October 29, 2013 11:46 AM No. ;-) What's wrong with me? Have I become a Rubyist, LOL? Thanks, clearly under-caffeinated today. /be js> 1.*2 2 - André Brendan Eich October 29, 2013 11:39 AM Got it, thanks. We cou

Re: Novel operator syntax

2013-10-29 Thread Tristan Zajonc
Right you are. That was the same issue with Python. Are there any blockers to ~*? On Tue, Oct 29, 2013 at 11:46 AM, André Bargull wrote: > Got it, thanks. We could indeed do .+, .*, etc. without ambiguity. >> (Ignore E4X's wildcards: xml.* etc.!) >> >> /be >> > > No. ;-) > > js> 1.*2 > 2 > > >

Re: Novel operator syntax

2013-10-29 Thread André Bargull
Got it, thanks. We could indeed do .+, .*, etc. without ambiguity. (Ignore E4X's wildcards: xml.* etc.!) /be No. ;-) js> 1.*2 2 - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Novel operator syntax

2013-10-29 Thread Brendan Eich
Dean Landolt wrote: The PEP Tristan posted offers a pretty compelling case for distinguishing elementwise operators from objectwise ones (although not for this dot syntax per se, they went with a ~-prefix): http://www.python.org/dev/peps/pep-0225/ Got it, thanks. We could indeed do .+, .*, et

Re: Proposal for new floating point and integer data types

2013-10-29 Thread Brendan Eich
Tristan Zajonc wrote: One clarification on the value objects proposal... The JSConf slides say that immutability is implemented as an implicit Object.freeze(this) on return in the constructor. Is this meant as shorthand for a deep freeze? Yes, although depth may be hard to generalize. A dee

Re: Novel operator syntax

2013-10-29 Thread Dean Landolt
The PEP Tristan posted offers a pretty compelling case for distinguishing elementwise operators from objectwise ones (although not for this dot syntax per se, they went with a ~-prefix): http://www.python.org/dev/peps/pep-0225/ On Tue, Oct 29, 2013 at 2:25 PM, Brendan Eich wrote: > Tristan Zajo

Re: Proposal for new floating point and integer data types

2013-10-29 Thread Tristan Zajonc
One clarification on the value objects proposal... The JSConf slides say that immutability is implemented as an implicit Object.freeze(this) on return in the constructor. Is this meant as shorthand for a deep freeze? On Tue, Oct 29, 2013 at 11:13 AM, Tristan Zajonc wrote: > On Tue, Oct 29, 2

Re: Novel operator syntax

2013-10-29 Thread Brendan Eich
Tristan Zajonc wrote: Sorry, at most I'm only proposing every *existing* operator prefixed by ., not new operators. So things like .+, ./, .*, .-., .%, .==, .!=, .>, .<, etc. These would be called dot operators. This is all that's required by the technical computing use case. Why is the do

Re: Novel operator syntax

2013-10-29 Thread Tristan Zajonc
On Tue, Oct 29, 2013 at 10:37 AM, Tab Atkins Jr. wrote: > On Tue, Oct 29, 2013 at 10:01 AM, Tristan Zajonc > wrote: > > Following up on the discussion about operator overloading, what are > viable > > options for introducing novel infix operators or a class of > > extended/prefixed operators? > >

Re: Proposal for new floating point and integer data types

2013-10-29 Thread Tristan Zajonc
On Tue, Oct 29, 2013 at 10:08 AM, Brendan Eich wrote: > Tristan Zajonc wrote: > >> >> It's true that in JS today, comparing an object to a non-object, >> valueOf or toString on the object can be used to make == results vary. >> >> However, I'm proposing value objects with declarative

Re: Proposal for new floating point and integer data types

2013-10-29 Thread Tristan Zajonc
On Tue, Oct 29, 2013 at 10:04 AM, Brendan Eich wrote: > Tristan Zajonc wrote: > >> >> if (mutMatA == mutMatB) { >> accidentallyMutate(mutMatA); >> assumeStillEqual(mutMatA, mutMatB, data); >> } >> >> >> Is this bug related to operator overloading? It seems just the nature

Re: Novel operator syntax

2013-10-29 Thread Tab Atkins Jr.
On Tue, Oct 29, 2013 at 10:01 AM, Tristan Zajonc wrote: > Following up on the discussion about operator overloading, what are viable > options for introducing novel infix operators or a class of > extended/prefixed operators? > > For motivation, I along with some others have implemented a MATLAB/R

Re: Proposal for new floating point and integer data types

2013-10-29 Thread Brendan Eich
Tristan Zajonc wrote: It's true that in JS today, comparing an object to a non-object, valueOf or toString on the object can be used to make == results vary. However, I'm proposing value objects with declarative syntax to solve several problems: 1. Backward compatibility, s

Re: Proposal for new floating point and integer data types

2013-10-29 Thread Brendan Eich
Tristan Zajonc wrote: if (mutMatA == mutMatB) { accidentallyMutate(mutMatA); assumeStillEqual(mutMatA, mutMatB, data); } Is this bug related to operator overloading? It seems just the nature of the beast with mutable reference types. Pretty much all JS matrix librari

Novel operator syntax

2013-10-29 Thread Tristan Zajonc
Following up on the discussion about operator overloading, what are viable options for introducing novel infix operators or a class of extended/prefixed operators? For motivation, I along with some others have implemented a MATLAB/R like environment for JS. We've written a compile-to-js language t

No HTML yet for rev 20

2013-10-29 Thread Jason Orendorff
It looks like ES6 draft rev 20 has dropped: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts I don't have time to update the HTML right now, so it'll be a few days. You'll be the first to know when it's fixed. -j ___ es-discuss mailin

Re: ArrayClass should imply @@isConcatSpreadable

2013-10-29 Thread Bjoern Hoehrmann
* Allen Wirfs-Brock wrote: >On Oct 28, 2013, at 5:52 PM, Domenic Denicola wrote: > >> From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] >> >>> So what's so onerous about returning a fresh array from the getter each >>> time it was called. >> >> The fact that `api.property !== api.property`.

Re: ArrayClass should imply @@isConcatSpreadable

2013-10-29 Thread Andreas Rossberg
On 28 October 2013 21:20, Boris Zbarsky wrote: > As far as I can tell, the two places in ES5 that test [[Class]] being equal > to "Array" are Array.isArray() and Array.prototype.concat. > > In ES6, the former does some sort of brand check, but the latter calls > IsConcatSpreadable, which checks fo

Re: ArrayClass should imply @@isConcatSpreadable

2013-10-29 Thread Boris Zbarsky
On 10/28/13 8:50 PM, Allen Wirfs-Brock wrote: So what's so onerous about returning a fresh array from the getter each time it was called. If it was implemented in Es6, it would just be: return Array.from(internal_compy); Implementing this is pretty easy, for sure. The questions are: 1)