On Mon, Oct 28, 2013 at 4:03 PM, Brendan Eich <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
