On Mon, Oct 28, 2013 at 8:14 AM, Brendan Eich <[email protected]> wrote:
> Tristan Zajonc <mailto:tristan@senseplatform.**com<[email protected]> >> > >> 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
