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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> >> 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 < >>> [email protected]> 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 <[email protected]> >>>> 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 <[email protected] >>>>> > 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 >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
