On Mon, Oct 28, 2013 at 4:03 PM, Brendan Eich <brendan at mozilla.com> 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)) {
    accidentallyMutate(mutMatA);
    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.

Tristan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131028/63e2775a/attachment.html>

On Mon, Oct 28, 2013 at 4:03 PM, Brendan Eich <brendan at mozilla.com> wrote:
> ```js
> 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:

```js
if (mutMatA.equals(mutMatB)) {
    accidentallyMutate(mutMatA);
    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?

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