> Tristan Zajonc <mailto: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?"

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

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

> 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/)?

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.

> Sorry if my comments are based on not understanding the proposal.

No worries,

/be

Tristan Zajonc <mailto: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?"

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

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

> 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/)?

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.

> Sorry if my comments are based on not understanding the proposal.

No worries,