If permutations of operators is a problem, couldn't it be resolved by assigning symbols to symbols?
For instance, to override a binary operator, one could just ``` Symbol['>>']['='] // >>= ``` Or something. On 31 December 2015 at 23:00, <[email protected]> wrote: > Send es-discuss mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.mozilla.org/listinfo/es-discuss > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of es-discuss digest..." > > Today's Topics: > > 1. Re: How should operator overloading work? (Nicolas B. Pierron) > 2. Re: How should operator overloading work? (Coroutines) > 3. Re: Backward running version look-behinds (Waldemar Horwat) > 4. Re: Backward running version look-behinds (Nozomu Kat?) > > > ---------- Forwarded message ---------- > From: "Nicolas B. Pierron" <[email protected]> > To: Coroutines <[email protected]> > Cc: es-discuss <[email protected]> > Date: Wed, 30 Dec 2015 16:31:52 +0000 > Subject: Re: How should operator overloading work? > Note, do we want to distinguish the binary operator Symbol['_+_'] from > the unary operator Symbol['+_']. > Also, I am not sure how extendable the language is, especially if we > are looking for operators like Symbol['_>>=_']. > > > On Tue, Dec 29, 2015 at 4:41 PM, Coroutines <[email protected]> wrote: > > How I imagined *binary* operator invocation would work is this: > > > > Our example: a + b > > > > If a or b is an object we try to look for an overloaded operator to > > call like so: > > > > (a[Symbol('+')] || b[Symbol('+')])(a, b) > > > > ^ disregard that I'm assuming both a and b are objects I can index safely > > > > Okay, so turns out neither a nor b have an overloaded operator for > > '+'. We default to calling the normal operator handler that coerces > > with valueOf() as necessary. > > > > To me this seemed rather simple.. Operators would just be defined > > like: some_object[Symbol('~')] = function (lhs, rhs) { ... } > > > > The only confusion I see is if we want to define explicitly the > > postfix or prefix form of unary operators like ++. I don't know what > > I'd call them as symbols. > > > > I always saw overloading operators with Symbols, but you could just > > have reserved member names on the prototype of the object as well ~ > > '++operator' similar to C++ ? > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > > -- > Nicolas B. Pierron > > > > ---------- Forwarded message ---------- > From: Coroutines <[email protected]> > To: "Nicolas B. Pierron" <[email protected]> > Cc: es-discuss <[email protected]> > Date: Wed, 30 Dec 2015 11:07:26 -0800 > Subject: Re: How should operator overloading work? > On Wed, Dec 30, 2015 at 8:31 AM, Nicolas B. Pierron > <[email protected]> wrote: > > Note, do we want to distinguish the binary operator Symbol['_+_'] from > > the unary operator Symbol['+_']. > > Also, I am not sure how extendable the language is, especially if we > > are looking for operators like Symbol['_>>=_']. > > The "C++ way" of naming these would probably be nicer, but maybe > something like this: > > obj[Symbol['operator+']] = (lhs, rhs) => ... > obj[Symbol['++operator'] = (rhs) => ... > obj[Symbol['operator>>='] = (lhs, rhs) => ... > > I saw that you wanted to say where the operator appears (if it's > binary, unary, postfix, or prefix) depending on the _ - but certain > operators (like >>=) can only be binary operators so there wouldn't be > any confusion unless we want to get into the land of defining custom > operators like in Ruby. :-) > > > > ---------- Forwarded message ---------- > From: Waldemar Horwat <[email protected]> > To: "Nozomu Katō" <[email protected]>, [email protected] > Cc: > Date: Wed, 30 Dec 2015 14:56:56 -0800 > Subject: Re: Backward running version look-behinds > On 12/11/2015 13:16, Nozomu Katō wrote: > >> I wonder if the person who wrote the spec for RegExp is on this list. I >> would like to ask one question: Was there any reason why the following >> steps were defined in the present order: >> >> 21.2.2.4 Alternative >> The production Alternative :: Alternative Term evaluates as follows: >> 1. Evaluate Alternative to obtain a Matcher m1. >> 2. Evaluate Term to obtain a Matcher m2. >> >> instead of: >> >> The production Alternative :: Term Alternative evaluates as follows: >> 1. Evaluate Term to obtain a Matcher m1. >> 2. Evaluate Alternative to obtain a Matcher m2. >> >> or, was it a matter of preference? If any side effect I am missing >> exists in the latter order, I need to reconsider or abandon my compact >> version. >> > > Those appear to have equivalent behavior. I just picked one when writing > the RegExp spec. > > Waldemar > > > > > ---------- Forwarded message ---------- > From: "Nozomu Katō" <[email protected]> > To: Waldemar Horwat <[email protected]>, [email protected] > Cc: > Date: Thu, 31 Dec 2015 20:48:54 +0900 > Subject: Re: Backward running version look-behinds > On Wed, 30 Dec 2015 14:56:56 -0800, Waldemar Horwat wrote: > > On 12/11/2015 13:16, Nozomu Katō wrote: > >> I wonder if the person who wrote the spec for RegExp is on this list. I > >> would like to ask one question: Was there any reason why the following > >> steps were defined in the present order: > >> > >> 21.2.2.4 Alternative > >> The production Alternative :: Alternative Term evaluates as follows: > >> 1. Evaluate Alternative to obtain a Matcher m1. > >> 2. Evaluate Term to obtain a Matcher m2. > >> > >> instead of: > >> > >> The production Alternative :: Term Alternative evaluates as follows: > >> 1. Evaluate Term to obtain a Matcher m1. > >> 2. Evaluate Alternative to obtain a Matcher m2. > >> > >> or, was it a matter of preference? If any side effect I am missing > >> exists in the latter order, I need to reconsider or abandon my compact > >> version. > > > > Those appear to have equivalent behavior. I just picked one when > > writing the RegExp spec. > > Thank you very much indeed for your comment. Then, my compact version is > likely to work expectedly. > > But it was first demonstrated by Claude that modifying "21.2.2.4 > Alternative" is the simplest way to support lookbehind assertions. So, I > think the spec for lookbehinds has basically been prepared by Claude. > > Nozomu > > > _______________________________________________ > 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
