<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 28, 2013 at 8:14 AM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com" target="_blank">brendan@mozilla.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Tristan Zajonc <mailto:<a href="mailto:tristan@senseplatform.com" target="_blank">tristan@senseplatform.<u></u>com</a>><br>
October 27, 2013 5:47 PM<div class="im"><br>
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?<br>

</div></blockquote>
<br>
Do you mean "what's the motivation for not applying operators to mutable objects too?"<div class="im"><br></div></blockquote><div><br></div><div>Yes.  My question was why not mutable objects too?  I definitely agree with the overall motivation.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>

</blockquote>
<br></div>
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 <=.</blockquote>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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).<br>

</blockquote>
<br></div>
What punctuators or (non-ASCII?) lexemes would you want for these operators?</blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The API Function.defineOperator(<u></u>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 (<a href="http://www.python.org/dev/peps/pep-0225/" target="_blank">http://www.python.org/dev/<u></u>peps/pep-0225/</a>)?<br>

</blockquote>
<br></div>
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.<div class="im"><br></div></blockquote><div><br></div><div>
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.  </div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Sorry if my comments are based on not understanding the proposal.<br>
</blockquote>
<br></div>
No worries,<br>
<br>
/be<br>
</blockquote></div><br></div></div>