operator overloading proposal
Christian Plesner Hansen
c7n at p5r.org
Sun Jun 19 07:51:42 UTC 2016
I'm not sure I'll be able to contribute much -- I've not kept up with JS
since around the time of the original discussion in 2009 and the
language has evolved a lot since then. But I have given the proposal
some thought since so I'll put those reflections out there in case
they're relevant to the discussion.
The original idea sprang from a discussion about adding a decimal type
to JS. I didn't think a decimal type belonged in the core of the
language and the suggestion was meant as a lesser evil. A way to support
decimal -- and longer term other types -- as libraries such that there
would be less pressure to put new types in the core language. (It wasn't
a hidden agenda either, in context; I talk about decimal in the original
email) Then decimal went away which reduced that pressure. Without
decimal as a greater evil I'm not sure I would have thought operator
overloading was a good idea even back then.
Today I don't think the proposal is very good. For one thing it's in the
flavor of 2009-era JS, and even back then it felt a little backward-
looking. It also conflates two things which should probably be
orthogonal: operator overloading and multiple dispatch. Operator
overloading is conceptually a simple mechanism, lots of languages
similar to JS has it. Multiple dispatch can be really powerful (in
practice if not in theory) but also potentially incredibly complex.
There are hard unsolved problems around it, particularly modularity.
If I was to put together a proposal today I would put the operator
overloading aspect aside first and focus on multiple dispatch. If there
is a solution, great -- but then I'd suggest providing that as a full
language feature in itself instead of conflating it with a convenient
operator syntax. Multiple dispatch is useful and if it can be supported
cleanly there is no reason to restrict it to methods with a particular
syntax -- that just creates a perverse incentive to express things in
terms of operators to get the multiple dispatch behavior when the
incentive should be purely that the syntax is appropriate. Or maybe no
acceptable multiple dispatch mechanism can be designed, or maybe adding
one isn't desirable even if there is a design. Either way the design
space for operator overloading has shrunk considerably, in bother cases
ideally to a thin syntactic layer on top of normal methods.
On Sun, Jun 5, 2016, at 03:22 PM, Benjamin Gruenbaum wrote:
> I see some discussion is happening - that's good.
> As I don't want to see the tremendous amount of work people put into
> value types and operator overloading go to waste - let's bring Brendan
> and Christian into this discussion and start with a link to Brendan's
> 2013 slides:
> Let's consider value semantics for this.
> > I've been working on implementing operator overloading and would
> > like to submit a proposal.
> > I think operator overloading would be a useful addition to the
> > language. In particular I think it would be useful for defining
> > operations on common mathematical object types such as complex
> > numbers, vectors, matrices, and sets.
> > I've create a working prototype that consists of:
> > babel plugin that rewrites operators as function calls
> > a polyfill which defines these functions and which call the correct
> > argument-specific function based on the arguments' prototypes
> > Function.defineOperator which can be used to define which function
> > an operator should use for the specified types
> > "use overloading" directive which allows users to opt-in
> > More details can be found at kevinbarabash/operator-overloading. The
> > babel plugin can be found at kevinbarabash/babel-plugin-operator-
> > overloading. I also have a demo project at kevinbarabash/operator-overloading-
> > demo.
> The design was inspired by some of the slides from www.slideshare.net/BrendanEich/js-
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss