operator overloading proposal

G. Kay Lee balancetraveller+es-discuss at gmail.com
Tue May 10 08:02:53 UTC 2016


Yes, I think exposing operators through well-known symbols is an
interesting idea worthy of more exploration because it's precisely the
purpose of well-known symbols to expose and allow manipulation to
previously inaccessible internal language behaviors.

On Tue, May 10, 2016 at 1:59 PM, Kevin Barabash <kevinb at khanacademy.org>
wrote:

> > And remember that decorators are essentially just a syntax to apply
> functions to objects/classes at design time, so what you're proposing is
> essentially some new global function, which is going against the current
> trend and effort to better modularize/namespace all these utility
> functions/methods.
>
> That's a really good point.
>
> > It has been mentioned and discussed in numerous places over the years,
> you can find more info on this with some casual googling. For example:
> https://news.ycombinator.com/item?id=2983420
>
> Thanks for the link.  I played around with sweet.js a bit over the
> weekend.  Using macros should work if we went with Python style operator
> overloading.  Instead of defining methods like _ADD_, _SUB_ etc. we could
> create some well-known symbols, maybe Symbol.plus, Symbol.times, etc.
>
> ```
> class Point {
>   constructor(x, y) {
>     Object.assign(this, {x, y});
>   }
>
>   [Symbol.add](other) {
>     return new Point(this.x + other.x, this.y + other.y);
>   }
> }
>
> const u = new Point(5, 10);
> const v = new Point(1, -2);
>
> const w = u + v;  // desugars to u[Symbol.add](v)
> console.log(w);   // { x: 6, y: 8 };
> ```
>
> This would require default implementations to be defined on
> Object.prototype for Symbol.plus, Symbol.times, etc.
>
>
> On Sun, May 8, 2016 at 10:38 PM, G. Kay Lee <
> balancetraveller+es-discuss at gmail.com> wrote:
>
>> > Why not? The standard defines well-known symbols. Maybe `@operator`
>> could be a well known decorator (assuming decorators get approved).
>>
>> Well... you make something into the standard with proposals, not
>> why-nots, so in order to make that happen you need to draft another
>> proposal for well-known decorators. And remember that decorators are
>> essentially just a syntax to apply functions to objects/classes at design
>> time, so what you're proposing is essentially some new global function,
>> which is going against the current trend and effort to better
>> modularize/namespace all these utility functions/methods. And maybe a new
>> mechanism could be drafted for these new well-known decorators, so that we
>> can hide these new functions somewhere... but by now I hope it's becoming
>> clear that it's introducing way too much new surface area for the language
>> in exchange for one small feature.
>>
>> > I haven't seen any proposals for macros, could you post a link?
>>
>> It has been mentioned and discussed in numerous places over the years,
>> you can find more info on this with some casual googling. For example:
>> https://news.ycombinator.com/item?id=2983420
>>
>>
>>
>> On Sun, May 8, 2016 at 2:51 PM, Kevin Barabash <kevinb at khanacademy.org>
>> wrote:
>>
>>> I should update the demo code to show the `@operator` decorator in
>>> addition to `Function.defineOperator`.
>>>
>>> Initially I started out with just the `@operator` decorator, but that
>>> meant that each class would have to have knowledge of each of the classes
>>> it might want to interact with before hand.  Having a separate
>>> `defineOperator` function avoids this situation.
>>>
>>> It means that prototype style classes must be converted to the new class
>>> syntax before operator overloading could be used.  Lastly, there may be
>>> some cases where it makes sense to overload operators with existing 3rd
>>> party code or built-in classes, e.g. adding set operations to Set using
>>> operator overloading.
>>>
>>> > It's also apparent that the `@operator decorator` part of the
>>> proposal is an effort trying to address this issue, but it really is not
>>> the responsibility of the standard to try to define such a thing.
>>>
>>> Why not?  The standard defines well-known symbols.  Maybe `@operator`
>>> could be a well known decorator (assuming decorators get approved).
>>>
>>> Slide 15 from http://www.slideshare.net/BrendanEich/js-resp shows
>>> syntax for defining operators in value types which could be adapted as
>>> follows for regular classes:
>>>
>>> ```
>>> class Point {
>>>    constructor(x, y) {
>>>        this.x = +x;
>>>        this.y = +y;
>>>    }
>>>    Point + Number (a, b) {
>>>        return new Point(a.x + b, a.y + b);
>>>    }
>>>    Number + Point (a, b) {
>>>        return new Point(a + b.x, a + b.y);
>>>    }
>>>    Point + Point (a, b) {
>>>        return new Point(a.x + b.x, a.y + b.y);
>>>    }
>>> }
>>> ```
>>>
>>> Having to define `+` twice for `Point + Number` and `Number + Point`
>>> seems like busy work, but maybe it's better to be explicit.  What are you
>>> thoughts about this syntax?
>>>
>>> > Another thing is that, IMHO, currently there are too much
>>> quirks/conventions in the proposal that feel non-evident and non-flexible
>>> which is destined to trip people over from time to time. It would be great
>>> to make a proposal that's simple and don't include too much assumptions.
>>>
>>> Could you elaborator what quirks/conventions might trip people up?
>>>
>>> > Finally, I'm not sure about the current status of macros, but last I
>>> heard of it, they say it's going to make its way into the standard pretty
>>> soon (TM), and macros can do much of the things overloading could, and much
>>> more.
>>>
>>> I haven't seen any proposals for macros, could you post a link?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, May 7, 2016 at 9:55 PM, G. Kay Lee <
>>> balancetraveller+es-discuss at gmail.com> wrote:
>>>
>>>> I'd say it's way too early to ask for a champion on this because just a
>>>> quick skimming revealed a lot of places that didn't add up. For example,
>>>> the proposal suggested that overloading is primarily targeted at making it
>>>> easier to work with user-defined classes, but curiously a
>>>> `Function.defineOperator()` method is proposed instead of some syntax that
>>>> feels more tightly integrated with the class definition syntax.
>>>>
>>>> ```
>>>>
>>>> class Point {
>>>>     constructor(x, y) {
>>>>         Object.assign(this, { x, y });
>>>>     }
>>>>
>>>>     toString() {
>>>>         return `(${this.x}, ${this.y})`;
>>>>     }
>>>> }
>>>> Function.defineOperator('+', [Point, Point], (a, b) => new Point(a.x + b.x, a.y + b.y));
>>>>
>>>> ```
>>>>
>>>> The demo code made this flaw evident - it looks like a giant step
>>>> backward to define an instance method like this, don't you agree?
>>>>
>>>> It's also apparent that the `@operator decorator` part of the proposal
>>>> is an effort trying to address this issue, but it really is not the
>>>> responsibility of the standard to try to define such a thing.
>>>>
>>>> What I'd suggest is that perhaps you should rethink your proposed
>>>> syntax and redesign it to become an extension of the ES6 class definition
>>>> syntax.
>>>>
>>>> Another thing is that, IMHO, currently there are too much
>>>> quirks/conventions in the proposal that feel non-evident and non-flexible
>>>> which is destined to trip people over from time to time. It would be great
>>>> to make a proposal that's simple and don't include too much assumptions.
>>>>
>>>> Finally, I'm not sure about the current status of macros, but last I
>>>> heard of it, they say it's going to make its way into the standard pretty
>>>> soon (TM), and macros can do much of the things overloading could, and much
>>>> more.
>>>>
>>>> On Sun, May 8, 2016 at 8:51 AM, Kevin Barabash <kevinb at khanacademy.org>
>>>> wrote:
>>>>
>>>>> I forgot to mention in my last email that I'm looking for a champion
>>>>> for this proposal.
>>>>>
>>>>> On Sat, May 7, 2016 at 5:24 PM, Kevin Barabash <kevinb at khanacademy.org
>>>>> > wrote:
>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> 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
>>>>>> https://github.com/kevinbarabash/operator-overloading.
>>>>>> The babel plugin can be found at
>>>>>> https://github.com/kevinbarabash/babel-plugin-operator-overloading.
>>>>>> I also have a demo project at
>>>>>> https://github.com/kevinbarabash/operator-overloading-demo.
>>>>>>
>>>>>> The design was inspired by some of the slides from
>>>>>> http://www.slideshare.net/BrendanEich/js-resp.
>>>>>>
>>>>>> – Kevin
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160510/402a880c/attachment-0001.html>


More information about the es-discuss mailing list