Proposal for new floating point and integer data types

Tristan Zajonc tristan at
Tue Oct 29 11:13:40 PDT 2013

On Tue, Oct 29, 2013 at 10:08 AM, Brendan Eich <brendan at> 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 syntax to
>>     solve several problems:
>>     1. Backward compatibility, so == uses cannot change unexpectedly
>>     on extant code, or grow performance hair in existing engines
>>     facing existing code.
>>     2. Solve the cross-frame problem where loading the same value
>>     class declaration results in the same typeof and other results for
>>     operations on values instantiated from equivalent declarations
>>     (details still being worked out).
>>     3. Facilitate functional programming, both for user benefit and
>>     for engines, which can better optimize based on immutable values
>>     (including stack allocation).
>> On 3, I think mutability is a required option for matrix libraries.
>>  While immutable matrix APIs are interesting, I do not believe anybody has
>> successfully implemented a flexible high performance immutable matrix
>> library in any language.  I think the key user demand is porting basic
>> MATLAB like numeric code to JS, which wouldn't be possible with an
>> immutable library.
> The Haskell folks will disagree with you, but I'll let them speak for
> themselves.
My point here is only that I don't think JS should adjudicate this debate
in the context of operators.  It seems like this discussion should happen
if a Matrix  type is added to the core of JS.  Having operators would
encourage the development of cow paths.

> Item 2 is important but hard to get right in the face of mutable objects
> and prototype chains.
I don't understand this issue well enough to comment.

> Can value objects / immutability be separated from operator overloading?
> Almost certainly. I'm starting with value objects because in design,
> leaving things out (without necessarily being future-hostile to extension)
> is generally better than trying to do include too much.
> The value class syntax (operator multimethods) that I showed at
> could easily be class syntax, as you surmised.

Got it.  I'm a fan of the syntax and dispatch mechanism.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list