additional Math function

Brendan Eich brendan at
Fri Nov 2 13:24:06 PDT 2012

David Herman wrote:
> On Nov 2, 2012, at 12:05 PM, Yehuda Katz<wycats at>  wrote:
>> Seems like a small surface-area with a large impact on compilers.
>> At first glance, looks good to me.
>> Curiosity: Does this overlap with Brendan's work on value objects (i.e. will it become moot in the face of them)
> It could become unnecessary if you're working with value objects. If you had ordinary numbers, you'd have to coerce them to u32 and then multiply:
>      var a = 0x7fffffff, b = 0x7fefefef; // both doubles
>      var result = int32(a) * int32(b);   // int32
> But value objects are still uncertain

I'm focusing on int64 and uint64 but making the framework as general 
under the hood as possible (e.g., the operators stuff, a multimethod 
variation that's inline-cacheable, based on an idea from Christian 
Plesner Hansen).

The need for 64-bit ints is pretty strong in Node.js and I think this 
means value objects are a priority for ES7.

>   and at the very least much farther off into the future -- post-ES6. Engines could implement and ship Math.imul in very short order.

Agreed, and this kind of micro-evolution is important to support even 
while working on value objects for post-ES6. It may be we end up with 
int32 and uint32, but we don't need to if there's no strong use-case not 
satisfied by Math.imul.

Note that there's no micro-evolutionary step involving Math.imul64 that 
satisfies the int64/uint64 use-cases Node faces (buffer and file 
sizes/offsets). You need 64-bit addition, subtraction, and probably 
other operators -- and you need the data type, not just operations that 
could be Math methods.


More information about the es-discuss mailing list