es-discuss Digest, Vol 106, Issue 76

John Gardner gardnerjohng at gmail.com
Thu Dec 31 12:34:45 UTC 2015


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, <es-discuss-request at mozilla.org> wrote:

> Send es-discuss mailing list submissions to
>         es-discuss at mozilla.org
>
> 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
>         es-discuss-request at mozilla.org
>
> You can reach the person managing the list at
>         es-discuss-owner at mozilla.org
>
> 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" <nicolas.b.pierron at mozilla.com>
> To: Coroutines <coroutines at gmail.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> 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 <coroutines at gmail.com> 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
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> --
> Nicolas B. Pierron
>
>
>
> ---------- Forwarded message ----------
> From: Coroutines <coroutines at gmail.com>
> To: "Nicolas B. Pierron" <nicolas.b.pierron at mozilla.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> 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
> <nicolas.b.pierron at mozilla.com> 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 <waldemar at google.com>
> To: "Nozomu Katō" <noz.ka at akenotsuki.com>, es-discuss at mozilla.org
> 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ō" <noz.ka at akenotsuki.com>
> To: Waldemar Horwat <waldemar at google.com>, es-discuss at mozilla.org
> 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
> 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/20151231/a9b119c9/attachment.html>


More information about the es-discuss mailing list