Re: Operator Overloading

2011-01-10 Thread Mike Shaver
On Mon, Jan 10, 2011 at 10:55 AM, Brendan Eich wrote: > In light of the incubation argument and big-ticket items, I don't think value > proxies break our complexity budget but they are very new. They're unlikely > to get into ES6. Let's keep discussing here and working on the wiki as > interest

Re: Operator Overloading

2011-01-10 Thread Brendan Eich
Mark's reply is good. Another point: we incubate strawman proposals for indefinite future editions, we do not prematurely cut because something doesn't fit in ES6. So the strawmay count does not indicate language complexity in the next edition. Also, bean-counting lots of little API wins of the

Re: Operator Overloading

2011-01-10 Thread Mark S. Miller
On Mon, Jan 10, 2011 at 2:12 AM, Erik Corry wrote: > 2011/1/10 thaddee yann tyl : > > I see no reason to name the "floordiv" trap that way. Python has a > > Agreed. > > On a slightly more high level note it seems like there is a very large > number of complex proposals being poured into Harmony.

Re: Operator Overloading

2011-01-10 Thread François REMY
?Well, you could implement BigNums with this proposal. You just need to make the assumption the browser use int32 to store integer numbers smaller than the max limit. Then, you build up an array that represent the big number, where arr[0] is its part from 0 to 2^32-1, arr[1] its part (=the bytes

Re: Operator Overloading

2011-01-10 Thread Erik Corry
2011/1/10 thaddee yann tyl : > I see no reason to name the "floordiv" trap that way. Python has a Agreed. On a slightly more high level note it seems like there is a very large number of complex proposals being poured into Harmony. If they are all implemented the language will become unwieldy an