Proposal for new floating point and integer data types

Tristan Zajonc tristan at
Mon Oct 28 23:06:39 PDT 2013

On Mon, Oct 28, 2013 at 4:03 PM, Brendan Eich <brendan at> wrote:

> Tristan Zajonc wrote:
>> Having === be reference equality is fine if that's a hard JS requirement.
>>  For a matrix API, there is some flexibility on comparison operators, but
>> transient value comparison returning a single boolean is the most natural,
>> other issues aside. I'm not sure I fully understand the bug you're worried
>> about though.
> 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 libraries
today use:

if (mutMatA.equals(mutMatB)) {
    assumeStillEqual(mutMatA, mutMatB, data);

which I assume would suffer from the same bug?

> 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.

Can value objects / immutability be separated from operator overloading?

>          A secondary issue, and probably a bigger can of worms, is
>>         whether the proposal will allow for additional operators.  For
>>         matrices, there is a well-defined and established set of
>>         operators that operate elementwise and objectwise (MATLABs
>>         dot-operators vs. operators).
>>     What punctuators or (non-ASCII?) lexemes would you want for these
>>     operators?
>> I'd want every operator prefixed by something (dot, tilde, colon).
> JS uses dot, tilde and colon. But let's not get stuck here. I suggest that
> novel operator syntax needs a fresh thread, and that it should be informed
> by the SweetJS experience so far.
Will do.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list