(apologies for top posting as I’m replying from my phone)
Functional operators are not very interesting on their own, but are much more
interesting in terms of pipelines and partial application. However, they may be
a stretch in either scenario, so I’m not expecting them to be part of any
official proposal for pipeline/partial application at this time.
By ergonomic, I meant that ‘{+}’ is far fewer characters than ‘Math.add’. Also,
not every ‘+’ is arithmetic (i.e. string concatenation).
I can imagine a world where I can do:
```js
const sum = numbers |> reduce(?, {+});
const joined = strings |> reduce(?, {+});
```
As a shorthand for:
```js
const sum = numbers |> reduce(?, (a, b) => a + b);
const joined = strings |> reduce(?, (a, b) => a + b);
```
(I’m using `|>` here for pipeline and `?` as a positional argument for partial
application here)
Ron
From: Darien Valentine<mailto:[email protected]>
Sent: Sunday, July 16, 2017 1:18 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: Re: Functional Operators
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
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
On Behalf Of Darien Valentine
Sent: Monday, July 10, 2017 3:08 PM
To: [email protected]<mailto:[email protected]>
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?)
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
