Proposal for new floating point and integer data types
tristan at senseplatform.com
Mon Oct 28 14:46:03 PDT 2013
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
>> 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
> 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
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
> 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
> Sorry if my comments are based on not understanding the proposal.
> No worries,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss