On Tue, Oct 29, 2013 at 10:08 AM, Brendan Eich <brendan at mozilla.com> 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 JSConf.eu
> 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: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131029/e22a444e/attachment.html>

On Tue, Oct 29, 2013 at 10:08 AM, Brendan Eich <brendan at mozilla.com> wrote:
> 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.

> 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 JSConf.eu
> could easily be class syntax, as you surmised.


Got it.  I'm a fan of the syntax and dispatch mechanism.