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);
}

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

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

/be

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.

```js
if (mutMatA == mutMatB) {
     accidentallyMutate(mutMatA);
     assumeStillEqual(mutMatA, mutMatB, data);
}
```

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

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