On Mon, Oct 28, 2013 at 8:14 AM, Brendan Eich <brendan at mozilla.com> wrote:

> Tristan Zajonc <mailto:tristan at senseplatform.**com<tristan at senseplatform.com>
>> >
>> October 27, 2013 5:47 PM
>>
>> I apologize for jumping in here with an incomplete understanding what's
>> being proposed, but perhaps somebody can help clarify it for me.  I've been
>> following value types and operator overloading discussion with great
>> interest.  From the slides and video, it appears that operator overloading
>> is only being discussed in the context of immutable value objects. Is this
>> right?  Or is it just what the examples use?  If operator overloading only
>> applies to value objects, what's the motivation?
>>
>
> Do you mean "what's the motivation for not applying operators to mutable
> objects too?"
>
>
Yes.  My question was why not mutable objects too?  I definitely agree with
the overall motivation.


>  I've implemented a large part of MATLAB/R like functionality in
>> JavaScript.  The biggest hurdle is a tolerable API for the core matrix and
>> dataframe types.  While perhaps silly, it's a deal breaker for some people
>> coming from other environments.  Otherwise, JS is an amazing platform,
>> particularly with ES6 features.
>>
>
> Mutable objects may want certain operators for convenience, but for
> mutable objects in JS, === must be reference (not transient value)
> identity, and == would be pretty bug-inducing if transient value comparing.
> Same comment for < and <=.


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.


>
>
>  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). You'd
call these dot-operators, colon-operators, or extended-operators.  One can
go round-and-round on whether all these are necessary, but for matrices
strictly separating objectwise/algebraic operators from
elementwise/broadcasting operators has many advantages.  The Julia and Mata
languages have both adopted this approach. In this scheme, matrix + 1 is an
error (they are not conformable for addition) and matrix .+ 1 is a matrix.
Combining these tends to lead to bugs. These details would be up to the
library though.


>
>  The API Function.defineOperator(**symbol, type1, type2) would be perfect
>> to support this. However I assume this is not the intention?  Is there any
>> openness to supporting user defined infix operators or at least an extended
>> set similar to Python's PEP 225 proposal (http://www.python.org/dev/**
>> peps/pep-0225/ <http://www.python.org/dev/peps/pep-0225/>)?
>>
>
> I'm not proposing syntactically novel operator extension. That is hard in
> a C-like language, but doable with enough work. It would be a separate
> proposal on top.
>
>
Complete flexibility is not necessary in the technical computing domain.
 Plenty of people have proposed more operators, but most are speculative
and there's definitely a valid concern of introducing too many esoteric
symbols.



>  Sorry if my comments are based on not understanding the proposal.
>>
>
> No worries,
>
> /be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131028/04a730ad/attachment.html>

On Mon, Oct 28, 2013 at 8:14 AM, Brendan Eich <brendan at mozilla.com> wrote:

> Do you mean "what's the motivation for not applying operators to mutable
> objects too?"

Yes.  My question was why not mutable objects too?  I definitely agree with
the overall motivation.


> Mutable objects may want certain operators for convenience, but for
> mutable objects in JS, === must be reference (not transient value)
> identity, and == would be pretty bug-inducing if transient value comparing.
> Same comment for < and <=.


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.


> What punctuators or (non-ASCII?) lexemes would you want for these
> operators?


I'd want every operator prefixed by something (dot, tilde, colon). You'd
call these dot-operators, colon-operators, or extended-operators.  One can
go round-and-round on whether all these are necessary, but for matrices
strictly separating objectwise/algebraic operators from
elementwise/broadcasting operators has many advantages.  The Julia and Mata
languages have both adopted this approach. In this scheme, matrix + 1 is an
error (they are not conformable for addition) and matrix .+ 1 is a matrix.
Combining these tends to lead to bugs. These details would be up to the
library though.

> I'm not proposing syntactically novel operator extension. That is hard in
> a C-like language, but doable with enough work. It would be a separate
> proposal on top.

Complete flexibility is not necessary in the technical computing domain.
 Plenty of people have proposed more operators, but most are speculative
and there's definitely a valid concern of introducing too many esoteric
symbols.