Re: Math.sign vs ±0

2013-10-30 Thread Claude Pache

Le 30 oct. 2013 à 04:54, Oliver Hunt oli...@apple.com a écrit :

 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 the rational for this behaviour?
 
 Current Math.sign is a new, and unexpectedly complex API that doesn’t solve 
 the common use case.
 
 —Oliver
 

`Math.sign` is expected to represent the mathematical sign function, which has 
a precise definition, see [1], [2]. Please note that `+0` and `-0` are the same 
value as far as maths is concerned, and that value is neither positive nor 
negative. (Or both nonnegative and nonpositive, if you prefer.) 

More generally, ES treats mathematically equal values as equal for any 
well-defined mathematical operation: doing otherwise would be new and 
unexpectedly complex (if you allow me to borrow your words).

—Claude

[1] http://mathworld.wolfram.com/Sign.html
[2] https://en.wikipedia.org/wiki/Signum_function

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Anne van Kesteren
On Tue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
 Spread now requires an Iterable rather than an array-like

This is different from how sequenceT behaves in IDL. (It uses array-likes.) :/


-- 
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: Math.sign vs ±0

2013-10-30 Thread Claude Pache

Le 30 oct. 2013 à 11:44, K. Gadd k...@luminance.org a écrit :

 Unfortunately Claude, ES Math.sign is not Signum; it has five outputs, not 
 three, like Oliver was asking about. Observe:
 
  Math.sign(1 / 0)
 1
  Math.sign(-1 / 0)
 -1
  Math.sign(-1 / 0 * 0)
 NaN
  Math.sign(0 * -1)
 -0
  Math.sign(0 * 1)
 0
 
 Signum as specified in your link produces three outputs: 0, -1, and 1.

Sure, ES `Math.sign` *cannot* be Signum, because real numbers *cannot* be 
represented in ES: Numbers in ES are just an *approximation* of a mathematical 
concept.

From a mathematical point of view, `+0` and `-0` is the same thing and `NaN` 
does not exist; so that `Math.sign` has really three meaningful outputs when 
interpreted mathematically: -1, 0, and 1. 

In general, I expect that the `Math` namespace to hold functions that 
correspond to definite mathematical operations, and to provide an approximation 
of those operations, as close as it is reasonable when taking in account the 
similarities and the differences between numbers in ES and numbers in maths. 
(From that point of view, I think that `Math.imul` and `Math.fround` should 
probably not belong to the `Math` namespace... but I digress.)

—Claude

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


RE: Math.sign vs ±0

2013-10-30 Thread Nathan Wall
Claude Pache wrote:
 `Math.sign` is expected to represent the mathematical sign
 function, which has a precise definition, see [1], [2].
 Please note that `+0` and `-0` are the same value as far as
 maths is concerned, and that value is neither positive nor
 negative. (Or both nonnegative and nonpositive, if you prefer.)

I don't think it's quite that cut and dry.  For one thing, the Wolfram resource 
you linked to states (at the very bottom):

    sgn(0) can also be interpreted as an unspecified point on the unit circle 
in the complex plane (Rich and Jeffrey 1996).

Since ES is (currently) limited to the Real numbers, that would make the only 
possible choices on the unit circle +1 and -1.  It wouldn't be such a leap to 
choose +1 for +0 and -1 for -0, given that IEEE/ES has both forms of 0.

Furthermore, +0 and -0 can have two different meanings.  They're used to 
represent the mathematical concept of 0 but they're also used to represent +ε 
and -ε respectively.  Since, sgn(+ε) = 1 and sgn(-ε) = -1, I think it would be 
a valid interpretation mathematically for `Math.sign(+0)` to be 1 and 
`Math.sign(-0)` to be -1.

At the very least, I think Oliver has a point in that it'd be very useful to 
have a sign function which would return 1 for +0 and -1 for -0.  I've needed 
this in the past.  If it shouldn't be `Math.sign`, perhaps there should be a 
`Number.sign` which would match the other use-case (one that I think would be 
more useful for meta-programming than what we have for `Math.sign`).

Nathan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


RE: Math.sign vs ±0

2013-10-30 Thread Nathan Wall
Nathan Wall wrote:
 At the very least, I think Oliver has a point in that it'd be very
 useful to have a sign function which would return 1 for +0 and -1
 for -0. I've needed this in the past. If it shouldn't be `Math.sign`,
 perhaps there should be a `Number.sign` which would match the other
 use-case (one that I think would be more useful for meta-programming
 than what we have for `Math.sign`).

On the other hand, it would probably confuse a lot of novice programmers who 
aren't familiar with IEEE 754 if sign(0) returned 1.  I could see that showing 
up in a list of JS WTFs. ;)

Nathan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Vyacheslav Egorov
Hi,

There are algorithms that require 64-bit arithmetic, however currently
JavaScript does not provide any efficient way to perform it.

Similar to Math.imul which was added for the purposes of efficient
32-bit multiplication I propose extending Math object with a family of
operations Math.s64op where s is one of {i, u} and op is one
of { sub, add, mul, div, neg }

These functions are specified as follows for op in { sub, add, mul, div }:

Math.s64op

1. accepts 4 arguments al, ah, bl, bh
2. x' = ToUint32(x), for x in {al, ah, bl, bh }
3. pairs (al', ah') and (bl', bh') are interpreted as 64-bit signed
(if s == i) or unsigned (if s == u) integer values with first
member of the pair containing low bits and second - high bits.
4. Result is computed as a standard overflowing operation on 64-bit
values and is decomposed into two int32 values (cl', ch') = (al', ah')
op (bl', bh')
5. A one shot property Math.H is created that returns ch' on the first
access and deletes itself.
6. Return cl'

Unary operation is specified in a similar straightforward fashion.

Here is addition of three unsigned 64bit integers using described functions:

var al, ah, bl, bh, cl, ch, dl, dh;

dl = Math.u64add(Math.u64add(al, ah, bl, bh), Math.H, cl, ch);
dh = Math.H;

This API is designed purposefully to allow good optimizations of the
resulting code, e.g. optimizing compiler knowing one shot semantics of
H property can eradicate any memory traffic and keep things in
registers even collocating (dl, dh) to a single 64-bit register on
64-bit platform.

I think such API has many advantages:

- can greatly improve performance of numeric algorithms relying on 64-bit math;
- easily polyfillable in the current JavaScript;
- does not depend on any complicated language changes (e.g. value objects);
- simple to implement and optimize on any platform (including 32bit ones);

--
Vyacheslav Egorov
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: Math.sign vs ±0

2013-10-30 Thread Allen Wirfs-Brock

On Oct 29, 2013, at 8:54 PM, Oliver Hunt wrote:

 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 the rational for this behaviour?
 
 Current Math.sign is a new, and unexpectedly complex API that doesn’t solve 
 the common use case.


It's just a matter of IEEE floats and consistency among the ESMath functions

Consistant handling of NaN requires that Math.sign(NaN) produces NaN.  So that 
means there needs to be at least four possible different return values from 
Math.sign. 

The fifth possible returned value derives from the handling of +/- 0.  If you 
look at the other Math function you will see the all of them(except for 
Math.abs) that map 0 to 0 preserve the sign of the 0 input.

Note that Java uses an identical definition for its signum function: 
http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html#signum%28float%29 

Finally, +0 and -0 compare as equal using both == and ===, so the impact of 
propagating -0 is small in mormal usage.?

Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Vyacheslav Egorov
 Rationale being faster polyfilled execution

The main reason for H being one shot is to allow optimizing compiler
*elide* updating it in most cases to eliminate memory traffic.

After thinking about it a bit I propose the following alternative step 5:

Math.H is from the very beggining a non-configurable non-writable
accessor property with a getter that returns hidden inner value and
always zeros inner value.

--
Vyacheslav Egorov


On Wed, Oct 30, 2013 at 5:28 PM, Olov Lassus olov.las...@gmail.com wrote:
 2013/10/30 Vyacheslav Egorov m...@mrale.ph

 5. A one shot property Math.H is created that returns ch' on the first
 access and deletes itself.


 Alternative step 5: Math.H is assigned ch'.

 Rationale being faster polyfilled execution, in combination with a lack of
 imagination from my side to come up with a use case where any code would be
 interested in knowing (at run-time) whether Math.H exists or not (i.e.
 whether it has already been read). Does such a use case exist?

 If all of JSC, Chakra, V8 et.al reliably optimizes away most overhead of a
 polyfilled Math.H getter then perhaps this does not matter.

 /Olov

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Olov Lassus
2013/10/30 Vyacheslav Egorov m...@mrale.ph

 5. A one shot property Math.H is created that returns ch' on the first
 access and deletes itself.


Alternative step 5: Math.H is assigned ch'.

Rationale being faster polyfilled execution, in combination with a lack of
imagination from my side to come up with a use case where any code would be
interested in knowing (at run-time) whether Math.H exists or not (i.e.
whether it has already been read). Does such a use case exist?

If all of JSC, Chakra, V8 et.al reliably optimizes away most overhead of a
polyfilled Math.H getter then perhaps this does not matter.

/Olov
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Olov Lassus
2013/10/30 Vyacheslav Egorov m...@mrale.ph

  Rationale being faster polyfilled execution

 The main reason for H being one shot is to allow optimizing compiler
 *elide* updating it in most cases to eliminate memory traffic.


Aaah. Thanks for pointing this out - I thought only of the polyfill
performance so I neglected this key aspect of your proposal.


 After thinking about it a bit I propose the following alternative step 5:

 Math.H is from the very beggining a non-configurable non-writable
 accessor property with a getter that returns hidden inner value and
 always zeros inner value.


+1 (for now) :)

/Olov
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Brendan Eich

Anne van Kesteren wrote:

OnTue, Oct 29, 2013  at 4:50 PM,  Allen Wirfs-Brock
al...@wirfs-brock.com  wrote:

  Spread now requires an Iterable rather than an array-like


This is different from how sequenceT  behaves in IDL. (It uses array-likes.) 
:/


This is more general, since array-likes should be iterable to be like 
arrays, which are iterable.


So this seems ok. Right?

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Anne van Kesteren
On Wed, Oct 30, 2013 at 5:14 PM, Brendan Eich bren...@mozilla.com wrote:
 Anne van Kesteren wrote:
 This is different from how sequenceT  behaves in IDL. (It uses
 array-likes.) :/

 This is more general, since array-likes should be iterable to be like
 arrays, which are iterable.

 So this seems ok. Right?

An array-like only length and properties 0, 1, ... as far as I
know. I thought iterable meant they implement the iterator protocol.


-- 
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Brendan Eich

Anne van Kesteren wrote:

On Wed, Oct 30, 2013 at 5:14 PM, Brendan Eichbren...@mozilla.com  wrote:

  Anne van Kesteren wrote:

  This is different from how sequenceT   behaves in IDL. (It uses
  array-likes.) :/


  This is more general, since array-likes should be iterable to be like
  arrays, which are iterable.

  So this seems ok. Right?


An array-like only length and properties 0, 1, ... as far as I
know. I thought iterable meant they implement the iterator protocol.


The meaning of array-like is evolving, maybe. I know, this means old 
array-likes don't iterate without work. Temporary migration problem?


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Vyacheslav Egorov
Some people find global state that this proposal introduces bad. I
see two ways addressing this:

- Returning {lo, hi} object.

Pros: no global state, in combination with destructuring allows to
write concise code, overhead can still be optimized away.
Cons: performance of polyfill is abysmal on bad and moderately good
VMs, requires allocation sinking pass to optimize away object
allocation.

- Make H property of the respective operation (e.g. u64mul updates its
own property H)

Pros: easy to implement, good perf on bad VMs
Cons: still kinda global state

- Math.s64op can become Math.createOperator(s64, op) that
returns function with H property:

var add = Math.createOperator(u64, add);
var dl = add(add(al, ah, bl, bh), add.H, cl, ch);
var dh = add.H;

Pros: no global state, relatively good performance on the non advanced
VMs, can be actually extended(!) e.g. SIMD operations can be exposed
as Math.createOperator(simd128, add)

--
Vyacheslav Egorov


On Wed, Oct 30, 2013 at 5:46 PM, Olov Lassus olov.las...@gmail.com wrote:
 2013/10/30 Vyacheslav Egorov m...@mrale.ph

  Rationale being faster polyfilled execution

 The main reason for H being one shot is to allow optimizing compiler
 *elide* updating it in most cases to eliminate memory traffic.


 Aaah. Thanks for pointing this out - I thought only of the polyfill
 performance so I neglected this key aspect of your proposal.


 After thinking about it a bit I propose the following alternative step 5:

 Math.H is from the very beggining a non-configurable non-writable
 accessor property with a getter that returns hidden inner value and
 always zeros inner value.


 +1 (for now) :)

 /Olov

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Boris Zbarsky

On 10/30/13 7:57 AM, Anne van Kesteren wrote:

On Tue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:

Spread now requires an Iterable rather than an array-like


This is different from how sequenceT behaves in IDL. (It uses array-likes.) :/


We could change that if we change all DOM arraylikesto be iterables 
(which they already are, I suspect).


The biggest compat issue will be cases that pass { length: 1, 0: x } 
to a sequenceDOMString or something, but do people do this in practice?


-Boris

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Andrea Giammarchi
* are gone


On Wed, Oct 30, 2013 at 11:00 AM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:

 This is promoting a fix in the `Object.prototype` ... and since I believe
 those dark days where `Object.prototype` shouldn't be touched due for/in
 loops, I like it ^_^

 Or maybe it's just a matter of `Arguments.prototype` , the most common non
 iterable always converted via slice?


 On Wed, Oct 30, 2013 at 10:26 AM, Brendan Eich bren...@mozilla.comwrote:

 Anne van Kesteren wrote:

 On Wed, Oct 30, 2013 at 5:14 PM, Brendan Eichbren...@mozilla.com
  wrote:

   Anne van Kesteren wrote:

   This is different from how sequenceT   behaves in IDL. (It uses
   array-likes.) :/

 
   This is more general, since array-likes should be iterable to be like
   arrays, which are iterable.
 
   So this seems ok. Right?


 An array-like only length and properties 0, 1, ... as far as I
 know. I thought iterable meant they implement the iterator protocol.


 The meaning of array-like is evolving, maybe. I know, this means old
 array-likes don't iterate without work. Temporary migration problem?

 /be

 __**_
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Allen Wirfs-Brock

On Oct 30, 2013, at 10:51 AM, Boris Zbarsky wrote:

 On 10/30/13 7:57 AM, Anne van Kesteren wrote:
 On Tue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock
 al...@wirfs-brock.com wrote:
 Spread now requires an Iterable rather than an array-like
 
 This is different from how sequenceT behaves in IDL. (It uses 
 array-likes.) :/
 
 We could change that if we change all DOM arraylikesto be iterables (which 
 they already are, I suspect).

All that is needed is to add an @@iterator method whose definition is identical 
to 
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.values 
ArrayIterator objects 
(http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array-iterator-object-structure
 ) will work fine with any Array-like objects.  But note that ES6 Rev20 has 
simplified them from what is shown at this link.

 
 The biggest compat issue will be cases that pass { length: 1, 0: x } to a 
 sequenceDOMString or something, but do people do this in practice?

Those are the sort of objects, that we decided to explicitly exclude from 
spread and for-of.  We could wrap an ArrayIterator around any object in those 
contexts that didn't have a @@iterator.  But that would mean that all objects 
would default to array-like iteration in those contexts.  When we discussed 
this we decided it is more likely that attempting to spreading or iterating 
over a object without a @@iterator is indication of a program bug.  So we throw 
on it.

For something like { length: 1, 0: x }, one way to make it iterable would 
be { length: 1, 0: x , [Symbol.iterator]: [].values}}


Allen


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Boris Zbarsky

On 10/30/13 2:28 PM, Allen Wirfs-Brock wrote:

All that is needed is to add an @@iterator method whose definition is
identical to
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.values


Right.  Pretty sure Gecko already ships just that (with a hack where we 
use an actual property named @@iterator, because we don't have 
internal symbols in SpiderMonkey yet) for WebIDL bindings with an 
indexed getter.



The biggest compat issue will be cases that pass { length: 1, 0: x
} to a sequenceDOMString or something, but do people do this in
practice?


Those are the sort of objects, that we decided to explicitly exclude
from spread and for-of.


Sure.  The question is whether we can compatibly exclude them from 
sequenceT in WebIDL.  I expect we can.


Anne, do you want to post to public-script-coord about this, or should I?

-Boris

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Anne van Kesteren
On Wed, Oct 30, 2013 at 7:01 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 10/30/13 2:28 PM, Allen Wirfs-Brock wrote:
 Those are the sort of objects, that we decided to explicitly exclude
 from spread and for-of.

 Sure.  The question is whether we can compatibly exclude them from
 sequenceT in WebIDL.  I expect we can.

 Anne, do you want to post to public-script-coord about this, or should I?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23683

(I mostly asked here first since the other breaking changes to IDL to
align with JavaScript haven't been very popular. But maybe this is
indeed small enough to get away with.)


-- 
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Allen Wirfs-Brock

On Oct 30, 2013, at 12:09 PM, Anne van Kesteren wrote:

 On Wed, Oct 30, 2013 at 7:01 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 10/30/13 2:28 PM, Allen Wirfs-Brock wrote:
 Those are the sort of objects, that we decided to explicitly exclude
 from spread and for-of.
 
 Sure.  The question is whether we can compatibly exclude them from
 sequenceT in WebIDL.  I expect we can.
 
 Anne, do you want to post to public-script-coord about this, or should I?
 
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23683
 
 (I mostly asked here first since the other breaking changes to IDL to
 align with JavaScript haven't been very popular. But maybe this is
 indeed small enough to get away with.)
 

Doesn't really depend upon the usage.  If an API is going to return a 
sequenceT to JS code, it really should have an @@iterator.  But that is 
presumably a non-breaking change, from the JS perspective.  If an API wants to 
accept a sequenceT it only needs it to have an @@iterator if it is actually 
going to use JS iterator semantics to process.  There is no reason that an 
implementation of such a consuming API couldn't do its own fall back to 
non-iterator based iteration.  That would be a non-breaking solution.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Anne van Kesteren
On Wed, Oct 30, 2013 at 7:23 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
 Doesn't really depend upon the usage.  If an API is going to return a 
 sequenceT to JS code, it really should have an @@iterator.  But that is 
 presumably a non-breaking change, from the JS perspective.  If an API wants 
 to accept a sequenceT it only needs it to have an @@iterator if it is 
 actually going to use JS iterator semantics to process.  There is no reason 
 that an implementation of such a consuming API couldn't do its own fall back 
 to non-iterator based iteration.  That would be a non-breaking solution.

This is about the accepting side, not returning. The idea was for that
was to be the same as the spread operator. Of course we could do
something else and have it compatible with current IDL semantics, but
that's not very coherent, nor desirable long term. So either the
spread operator changes or we change sequenceT. Going forward it'd
be great if we tried to reason about these things platform-wide,
rather than JavaScript-wide.


-- 
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Allen Wirfs-Brock

On Oct 30, 2013, at 12:29 PM, Anne van Kesteren wrote:

 On Wed, Oct 30, 2013 at 7:23 PM, Allen Wirfs-Brock
 al...@wirfs-brock.com wrote:
 Doesn't really depend upon the usage.  If an API is going to return a 
 sequenceT to JS code, it really should have an @@iterator.  But that is 
 presumably a non-breaking change, from the JS perspective.  If an API wants 
 to accept a sequenceT it only needs it to have an @@iterator if it is 
 actually going to use JS iterator semantics to process.  There is no reason 
 that an implementation of such a consuming API couldn't do its own fall back 
 to non-iterator based iteration.  That would be a non-breaking solution.
 
 This is about the accepting side, not returning. The idea was for that
 was to be the same as the spread operator. Of course we could do
 something else and have it compatible with current IDL semantics, but
 that's not very coherent, nor desirable long term. So either the
 spread operator changes or we change sequenceT. Going forward it'd
 be great if we tried to reason about these things platform-wide,
 rather than JavaScript-wide.

I don't understand what is special about the web APIs in this regard.  On the 
accepting side in ES we generally allow no breaking changes.  Wherever there 
was an existing API that accepted old-style array likes we now first test for 
@@iterator and then fall back to the legacy behavior.  If there are web APIs 
that currently accept array-likes and you don't do this then you are really 
to accept a lower bar for backward compatibility than what TC39 has been 
willing to accept.

I really don't see why sequenceT should be an issue here.  It's just part of 
a specification language and if you are going to have it, it needs to deal with 
reality.  If you currently have APIs that use sequenceT to accept array-like 
arguments, those API should continue to accept array-like arguments, regardless 
of changes you make to WebIDL.  Maybe that means that specifications need to 
change to using a Union of  sequenceT or arraylikeT.  But that's just one 
solution and really just a meta issue.  It doesn't change the legacy that has 
been implemented and that needs to continue to work.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Boris Zbarsky

On 10/30/13 3:23 PM, Allen Wirfs-Brock wrote:

If an API is going to return a sequenceT to JS code


Then it becomes a JS Array object in JS.  So there is no change here.


If an API wants to accept a sequenceT it only needs it to have an @@iterator 
if it is actually going to use JS iterator semantics to process.


Sequences always use those semantics, since the first thing they do, in 
the IDL layer before entering the actual API implementation, is make a 
copy of the list.  See http://dev.w3.org/2006/webapi/WebIDL/#es-sequence


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Luke Wagner
Just to be sure, do you agree that both the {lo, hi}-returning API and the 
magic-property API should both be able to achieve equivalent performance on a 
JS engine that has specifically added and optimized these int64 builtins?  I 
think this is true.

Assuming so, the reason to prefer the rather more awkward magic-property API 
would be purely because its polyfill is more efficient.  This is a tough 
choice, but it seems like bending the spec for the polyfill is overly 
conservative in this case.  A lot of the use cases I hear for int64 come from 
crypto and other very specific algorithms which already have implementations in 
JS.  In such cases, it seems like the authors have to write a new version of 
the algorithm using the new builtins anyway so, if performance was important, 
they could just keep around the old version and pick which version to call 
based on whether the new builtins are present.  Or they can just wait until the 
optimization is broadly available before switching.

The other main use case I can think of is large compiled C++ codebases.  
However, in our experience, C++ codebases tend not to heavily use int64 so the 
overhead of the polyfill would be less significant.

Are there any other use cases you have in mind that really demand high polyfill 
performance?

API considerations aside, though, I like the idea of bringing fast 64-bit 
arithmetic to JS without waiting for value objects.

Cheers,
Luke
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Vyacheslav Egorov
Yes, all API variants I have proposed should result in the equivalent
performance, to the best of my knowledge.

I would even say that {lo, hi} one is easier on VMs for two reasons:

- VMs tend to have some sort of escape analysis / allocation sinking
and they can incorporate { lo, hi } support into this pass;

- If VM desires to allocate { lo, hi } value to a single register it
might be easier to do that when values are explicitly grouped, VM does
not have to rediscover pairing --- it is already there.

You also correctly reasoned that I proposed magic property API for the
purposes of faster polyfilling.

So given the choice between { lo, hi } and magical property API if I
would prefer { lo, hi } iff I ignore polyfill performance.

 The other main use case I can think of is large compiled C++ codebases

I saw crypto libraries (e.g. NaCl) heavily relying on 64bit arithmetic.

 Are there any other use cases you have in mind that really demand high 
 polyfill performance?

I am interested in the whole number hierarchy actually (int32 - int64
- bigint). But I have no clear idea what to do here.

One possibility would be to allow passing type arrays alongside with
primitive numbers into something Math.bigop. But this is pretty ugly
and probably also results in abysmal polyfill performance.


--
Vyacheslav Egorov


On Wed, Oct 30, 2013 at 9:56 PM, Luke Wagner l...@mozilla.com wrote:
 Just to be sure, do you agree that both the {lo, hi}-returning API and the 
 magic-property API should both be able to achieve equivalent performance on a 
 JS engine that has specifically added and optimized these int64 builtins?  I 
 think this is true.

 Assuming so, the reason to prefer the rather more awkward magic-property API 
 would be purely because its polyfill is more efficient.  This is a tough 
 choice, but it seems like bending the spec for the polyfill is overly 
 conservative in this case.  A lot of the use cases I hear for int64 come from 
 crypto and other very specific algorithms which already have implementations 
 in JS.  In such cases, it seems like the authors have to write a new version 
 of the algorithm using the new builtins anyway so, if performance was 
 important, they could just keep around the old version and pick which version 
 to call based on whether the new builtins are present.  Or they can just wait 
 until the optimization is broadly available before switching.

 The other main use case I can think of is large compiled C++ codebases.  
 However, in our experience, C++ codebases tend not to heavily use int64 so 
 the overhead of the polyfill would be less significant.

 Are there any other use cases you have in mind that really demand high 
 polyfill performance?

 API considerations aside, though, I like the idea of bringing fast 64-bit 
 arithmetic to JS without waiting for value objects.

 Cheers,
 Luke
 ___
 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: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread David Herman
On Oct 30, 2013, at 1:56 PM, Luke Wagner l...@mozilla.com wrote:

 Just to be sure, do you agree that both the {lo, hi}-returning API and the 
 magic-property API should both be able to achieve equivalent performance on a 
 JS engine that has specifically added and optimized these int64 builtins?  I 
 think this is true.
 
 Assuming so, the reason to prefer the rather more awkward magic-property API 
 would be purely because its polyfill is more efficient.  This is a tough 
 choice, but it seems like bending the spec for the polyfill is overly 
 conservative in this case.  A lot of the use cases I hear for int64 come from 
 crypto and other very specific algorithms which already have implementations 
 in JS.  In such cases, it seems like the authors have to write a new version 
 of the algorithm using the new builtins anyway so, if performance was 
 important, they could just keep around the old version and pick which version 
 to call based on whether the new builtins are present.  Or they can just wait 
 until the optimization is broadly available before switching.

Agreed -- the magic-property API is pretty astoundingly wacky, and definitely 
not worth it.

 The other main use case I can think of is large compiled C++ codebases.  
 However, in our experience, C++ codebases tend not to heavily use int64 so 
 the overhead of the polyfill would be less significant.

I'm open to the {lo, hi} version of the API as a stopgap, but since we don't 
see a big need for it in compiled codebases and it's warm beer for human 
programmers, then looking at Slava's rationale...

 I think such API has many advantages:
 
 - can greatly improve performance of numeric algorithms relying on 64-bit 
 math;
 - easily polyfillable in the current JavaScript;
 - does not depend on any complicated language changes (e.g. value objects);
 - simple to implement and optimize on any platform (including 32bit ones);

...I'd say it's not particularly necessary for the short-term, and it's 
definitely not sufficient for the long-term. We can and must do better for 
programmers than declare {lo, hi} as a realistic API for 64-bit integers. Value 
types are in JS's future.

 API considerations aside, though, I like the idea of bringing fast 64-bit 
 arithmetic to JS without waiting for value objects.

As I say, I could see doing the less wacky API for short-term, but I don't 
think it's vital.

Dave

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss