If I understand right, Ron, it means a new RHS for PrimaryExpression and
would behave like a reference, except that it is (presumably) not a valid
assignment target? Can you explain more about the ergonomics — maybe it’s
just from lack of familiarity, but to me this seems pretty grawlixy, like
something you’d see in Perl.

In other words, I’m unsure how `arr.reduce({+})` is more ergonomic than
`arr.reduce(Math.add)`\*. Assuming it is and I’m just failing to see it, is
the benefit significant enough to merit new syntax?

(On further consideration, maybe `Reflect.add`, since `+` is not specific
to numeric values...)

On Sun, Jul 16, 2017 at 2:19 AM, Ron Buckton <Ron.Buckton at microsoft.com>
wrote:

> I have been looking into functional operators while working on a proposal
> for pipeline and partial application. I’ve found that a sigil like `{+}` is
> just as ergonomic as `(+)`, but has fewer lookahead issues with respect to
> regular expression parsing. While `(/)` is ambiguous as to whether it would
> be a division function or the start of a parenthesized regular expression
> literal, `{/` is far less ambiguous in most expression positions. The only
> ambiguity is at the statement level where `{/` could be interpreted as the
> start of a block with a regular expression literal. However, it is fairly
> unlikely this expression would be used in this position, and this can be
> mitigated using parentheses just as we do for object assignment patterns in
> destructuring assignments.
>
>
>
> The other ambiguous case is how to differentiate between overloaded binary
> and unary operators. For that, I’ve considered following the approach taken
> by F# and prefixing overloaded unary operators with tilde. As such `{+}`
> would always be a binary plus function, while `{~+}` would be the unary
> plus function. In the same vein, `{-}` would be binary minus, while `{~-}`
> would be the unary minus function. For non-overloaded unary operators the
> prefix is unnecessary, so `{~}` and `{!}` would not be prefixed.
>
>
>
> While built-ins could serve this case, they are far less ergonomic than a
> shorthand sigil for an operator. On the other hand, we could have both,
> with the operator sigils acting as shorthand for the long-form built-in
> methods. Either way, I would expect `{+} === {+}` as there is no sense in
> allocating a fresh function object each time it is encountered. Ideally,
> these would be frozen functions that are created once per realm and have
> the same semantics as an arrow function (i.e. [[Call]] but no
> [[Construct]], etc.).
>
>
>
> Ron
>
>
>
> *From:* es-discuss [mailto:es-discuss-bounces at mozilla.org] *On Behalf Of *Darien
> Valentine
> *Sent:* Monday, July 10, 2017 3:08 PM
> *To:* es-discuss at mozilla.org
> *Subject:* Re: Re: Functional Operators
>
>
>
> Minor point regarding the syntax given here: introducing `(/)` would
> likely be problematic because it breaks the constraint that there are no
> positions in the grammar where both a division operator and a regular
> expression literal could be valid continuations.
>
>
>
> (Perhaps new built-ins like `Math.add` etc might represent a more
> consistent approach to the issue of operators not being function
> references?)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170716/25422694/attachment-0001.html>

If I understand right, Ron, it means a new RHS for PrimaryExpression which
would behave like a reference, except that it is (presumably) not a valid
assignment target? Is `{+}.length`, etc, then valid? Can you explain more
about the ergonomics — maybe it’s just from lack of familiarity, but to me
this seems pretty grawlixy, like something you’d see in Perl.

In other words, I’m unsure how `arr.reduce({+}, 0)` is more ergonomic than
`arr.reduce(Math.add, 0)`\*. Assuming it is and I’m just failing to see it, is
the benefit significant enough to merit new syntax?

(On further consideration, maybe `Reflect.add`, since `+` is not specific
to numeric values...)

If I understand right, Ron, it means a new RHS for PrimaryExpression which
would behave like a reference, except that it is (presumably) not a valid
assignment target? Can you explain more about the ergonomics — maybe it’s
just from lack of familiarity, but to me this seems pretty grawlixy, like
something you’d see in Perl.

In other words, I’m unsure how `arr.reduce({+}, 0)` is more ergonomic than
`arr.reduce(Math.add, 0)`\*. Assuming it is and I’m just failing to see it, is
the benefit significant enough to merit new syntax?

(On further consideration, maybe `Reflect.add`, since `+` is not specific
to numeric values...)

If I understand right, Ron, it means a new RHS for PrimaryExpression and
would behave like a reference, except that it is (presumably) not a valid
assignment target? Can you explain more about the ergonomics — maybe it’s
just from lack of familiarity, but to me this seems pretty grawlixy, like
something you’d see in Perl.

In other words, I’m unsure how `arr.reduce({+}, 0)` is more ergonomic than
`arr.reduce(Math.add, 0)`\*. Assuming it is and I’m just failing to see it, is
the benefit significant enough to merit new syntax?

(On further consideration, maybe `Reflect.add`, since `+` is not specific
to numeric values...)