y, July 16, 2017 3:54 PM
To: Darien Valentine <valentin...@gmail.com>; es-discuss@mozilla.org
Subject: RE: Re: Functional Operators
(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 te
rom: Darien Valentine<mailto:valentin...@gmail.com>
Sent: Sunday, July 16, 2017 1:18 AM
To: es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
Subject: Re: Re: Functional Operators
If I understand right, Ron, it means a new RHS for PrimaryExpression and would
behave like a referen
on
>
>
>
> *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 sy
. [[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
+1 on the idea, -1 on the execution. Here's a few things to be aware of:
- A single unary or binary operator without parentheses is unambiguous
where only expressions are allowed.
- If the operators directly desugar to lambdas, you'll have functions that
look `===`, but aren't.
- The operator `-`
-1
i can see this becoming a debugging nightmare in math libraries where its
confused with arithmetic expressions.
yet-another-alien-syntax to remember when debugging other people's code.
On Jul 11, 2017 03:35, "Vihan Bhargava" wrote:
> As JS/ECMAScript gains more and more of
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
7 matches
Mail list logo