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-boun...@mozilla.org] On Behalf Of Darien
Valentine
Sent: Monday, July 10, 2017 3:08 PM
To: es-discuss@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?)
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
