Destructuring equivalent to nullish coalescing and optional chaining operators?

[liorean]

Hello!

Has any equivalent feature for the nullish coalescing ?? and optional
chaining ?. operators been proposed to paper over the deficiencies of
the destructuring syntax with regards to null values?

If not, I think one should be proposed. For the entire right side of
the binding, an equivalent to the default parameter = operator but
which also works on nulls would do very nicely. Reusing a token that
already exists, it could even be the nullish coalescing ?? operator,
though I feel like it would look neater with for example ?= even
though that would add an extra token to parse.

Likewise, I feel like an equivalent to the optional chaining ?.
operator that permit you to leave parameters undefined if the argument
is null or undefined could be useful. For undefined we can at least
receive an undefined argument and not having it error out using
default parameter {prop}={}, but we cannot do that for null.

I'd like to at least be able to in my function contracts guarantee
that the destructuring part, which is honestly neither the caller's
responsibility (because they cannot change what happens when I
destructure in my parameter list) nor is it the function's
responsibility (because destructuring is supposed to abstract away the
setup so we don't need to do it in the function body), happens without
causing errors. Right now null is a big hole in that - no matter what
we do, the only solution is to move setup into the function body
itself, which is exactly what we have destructuring to avoid.
-- 
David "liorean" Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Consistency in common operators across various types.

[Wesley Oliver]

Hi,

I have decided to put to gather a document, logically thinking about a
scripting language holistically on how to achieve
type free scripting language that is consistent and predictable regardless
of the data option which is operating.
In other words, a script problem is type invariant and input and outputs
will never differ base on any implicit, inferable, or backing types.


*Rules and constraint for writing a good scripting language or script for
that matter, such that it has consistent predictable and usable behaviour*

https://docs.google.com/document/d/1065G_MqNMFL_fBhSHSfH3ju0FUKC5iRpbj1iVwgAh3o/edit?usp=sharing

Kind Regards,

Wesley Oliver

On Fri, Apr 10, 2020 at 3:33 PM Wesley Oliver  wrote:

> Hi,
>
> Just like to maybe challenge javascript here or any script language in
> that mater.
>
> The definition of comparing two variables with an operator such as
> <.<=,>,>= of  the operators above definition changes depending on the left
> and right backing types.
>
> If both are strings then it does string comparison if both numbers then
> its numbers.
> Seem great but there are small gotchas.
>
> So if someone writes an algorithm and some gives them some badly formatted
> data, where some values are strings and some are numbers or what eva,
> because we are operating in type free space.
> Then sometimes the correct behaviour will be happening depending on what
> the intention is.
> string comparison or number comparison.
> Some of the loops evaluate the data going to be doing all sort wonderfully
> things,  flipping between definitions. kinda works for sort single
> numerical string sort method but not for logical algorithm comparisons,
> because they may and much work from time to time depending on the input
> data.
>
> Reason for a scripting language is be free of types and not care about
> different types, that things just work, but clearly there some additional
> corner cases, we need to improve on.
>
> The problem here is that based on the types the operator behaviour is
> inconsistent.
> To write script programs the behaviour for different operators needs to
> remain the same
> regardless of types. Else can't have data streams that data types don't
> matter and when algorithms basically break, then what was the point of
> using a type language.
>
> So in future for script languages, implement functions if there is
> conflict in that operator definition is not consistent across all types.
> This would allow use to write algorithms,
> were don't care about the types, else must ensure that * 1 before
> comparison or that
> format all the data on input, which requires projection and doubles memory
> usage, which then sucks, incremental versus balk conversion.
>
> For scripting language, the operator definition should remain the same,
> regardless of the left hand or right-hand side types thought out the
> language.
>
> A scripting language should choose base type in which these operators will
> be evaluated and everything will be coerced into that base operator type
> first.
>
> You could implement scope blocks, were one could choose operator base type
> so simplify code writing and understanding.
>
> [<,<=,+.,>]:string {
>
> }
>
> [comp-ops]:number {
>
> }
> Consistency and behaviour consistent across types is key to scripting
> language becoming more powerful. Rather use the function in future if there
> is no consistency across backing types for the operator.
>
> Kind Regards,
>
> Wesley Oliver
>
> --
> 
> GitHub:https://github.com/wesleyolis
> LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
> Blog/Website:https://sites.google.com/site/wiprogamming/Home
> Skype: wezley_oliver
> MSN messenger: wesley.o...@gmail.com
>
>
> --
> 
> GitHub:https://github.com/wesleyolis
> LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
> Blog/Website:https://sites.google.com/site/wiprogamming/Home
> Skype: wezley_oliver
> MSN messenger: wesley.o...@gmail.com
>


-- 

GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.o...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Consistency in common operators across various types.

[Wesley Oliver]

Hi,

Just like to maybe challenge javascript here or any script language in that
mater.

The definition of comparing two variables with an operator such as
<.<=,>,>= of  the operators above definition changes depending on the left
and right backing types.

If both are strings then it does string comparison if both numbers then its
numbers.
Seem great but there are small gotchas.

So if someone writes an algorithm and some gives them some badly formatted
data, where some values are strings and some are numbers or what eva,
because we are operating in type free space.
Then sometimes the correct behaviour will be happening depending on what
the intention is.
string comparison or number comparison.
Some of the loops evaluate the data going to be doing all sort wonderfully
things,  flipping between definitions. kinda works for sort single
numerical string sort method but not for logical algorithm comparisons,
because they may and much work from time to time depending on the input
data.

Reason for a scripting language is be free of types and not care about
different types, that things just work, but clearly there some additional
corner cases, we need to improve on.

The problem here is that based on the types the operator behaviour is
inconsistent.
To write script programs the behaviour for different operators needs to
remain the same
regardless of types. Else can't have data streams that data types don't
matter and when algorithms basically break, then what was the point of
using a type language.

So in future for script languages, implement functions if there is conflict
in that operator definition is not consistent across all types. This would
allow use to write algorithms,
were don't care about the types, else must ensure that * 1 before
comparison or that
format all the data on input, which requires projection and doubles memory
usage, which then sucks, incremental versus balk conversion.

For scripting language, the operator definition should remain the same,
regardless of the left hand or right-hand side types thought out the
language.

A scripting language should choose base type in which these operators will
be evaluated and everything will be coerced into that base operator type
first.

You could implement scope blocks, were one could choose operator base type
so simplify code writing and understanding.

[<,<=,+.,>]:string {

}

[comp-ops]:number {

}
Consistency and behaviour consistent across types is key to scripting
language becoming more powerful. Rather use the function in future if there
is no consistency across backing types for the operator.

Kind Regards,

Wesley Oliver

-- 

GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.o...@gmail.com


-- 

GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.o...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Suggestion: Infix operators/functions

[Thiago Brevidelli]

As stated in here, the TypeScript team is highly unlikely to deviate from 
ECMAScript’s team decisions, so I guess no infix functions in TS for now...

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Infix operators/functions

[Alexander Jones]

Time to put infix operators into TypeScript, first, then?

On Sat, 3 Feb 2018 at 04:25, kdex <k...@kdex.de> wrote:

> People in the C++ community have been using overloaded operators since the
> 1980's, and I wouldn't say that different semantics for the same operator
> have
> been a bad idea at all, given that the operator handles completely
> different
> types (that can and should be statically analyzable).
>
> I wouldn't even think that these features are abused in the C++ community:
> Think vector/matrix operations, for instance. Very expressive stuff.
>
> Depending on the application, it could be nicer for Array + Array to become
> Array(Array, Array) rather than Array(...Array, ...Array). Depends on your
> use
> case. As for function composition, it's a matter of preference if A + B is
> supposed to mean (...args) => A(B(...args)) or rather (...args) =>
> B(A(...args)).
>
> My point is, as long as there is a statically analyzable definition for how
> operators are supposed to behave for a given set of input types, there's no
> reason not to give programmers the ability to provide such definitions.
>
> But again, these discussions will be much more relevant if proposals such
> as
> [this one](https://github.com/sirisian/ecmascript-types) are discussed for
> standardization at some point.
>
> On Saturday, February 3, 2018 4:57:34 AM CET Naveen Chawla wrote:
> > I don't like the idea of custom operators only because of readability of
> > code - it can be different for different pieces of code, and so I think
> it
> > is a larger surface area for bugs, so I think it would be a net negative.
> >
> > However, I do like the idea of allowing e.g. `+` to be used intuitively
> and
> > consistently (i.e. with a fixed meaning) between certain data types that
> > are not currently supported, e.g.:
> >
> > Array + Array (array concatenation)
> > Function + Function (function composition)
> >
> > On Fri, 2 Feb 2018 at 22:02 Michael Haufe <t...@thenewobjective.com>
> wrote:
> > > How would operator precedence work? Would we be restricted to
> 2-argument
> > > functions only?
> > >
> > > On Fri, Feb 2, 2018 at 5:55 AM, Thomas Grainger <tagr...@gmail.com>
> wrote:
> > >> I'm porting this from the TypeScript issue tracker, original from:
> > >> https://github.com/Microsoft/TypeScript/issues/2319#issue-60851953
> > >>
> > >> Since it's very unlikely that the extension methods will ever be
> > >> implemented [in a call-site-rewrite
> > >> manner](
> > >>
> https://github.com/Microsoft/TypeScript/issues/9#issuecomment-74302592),
> > >> please consider adding infix operators to enable writing in functional
> > >> style similarly to what can be done in Haskell:
> > >>
> > >> Monoids
> > >>
> > >> ```js
> > >>
> > >> function '+' (left, right) {
> > >>
> > >>return left.concat(right);
> > >>
> > >> }
> > >>
> > >> [1, 2, 3] '+' [4, 5]; // [1, 2, 3, 4, 5]
> > >>
> > >> ```
> > >>
> > >> Monads
> > >>
> > >> ```js
> > >>
> > >> function '>>=' (promise, bind) {
> > >>
> > >>return promise.then(bind);
> > >>
> > >> }
> > >> $.get('/get') '>>=' x => $.post('/save', x + 1)
> > >>
> > >> ```
> > >>
> > >> Functors
> > >>
> > >> ```js
> > >>
> > >> function '.' (inner, outer) {
> > >>
> > >>return function(value: a) : c {
> > >>
> > >>   return outer(inner(value))
> > >>
> > >>}
> > >>
> > >> }
> > >>
> > >> function f(x) { }
> > >> function g(y) { }
> > >> (f '.' g)(x); // z
> > >>
> > >> ```
> > >>
> > >>
> > >>
> > >> Thomas Grainger
> > >>
> > >> ___
> > >> es-discuss mailing list
> > >> es-discuss@mozilla.org
> > >> https://mail.mozilla.org/listinfo/es-discuss
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Infix operators/functions

[kdex]

People in the C++ community have been using overloaded operators since the 
1980's, and I wouldn't say that different semantics for the same operator have 
been a bad idea at all, given that the operator handles completely different 
types (that can and should be statically analyzable).

I wouldn't even think that these features are abused in the C++ community: 
Think vector/matrix operations, for instance. Very expressive stuff.

Depending on the application, it could be nicer for Array + Array to become 
Array(Array, Array) rather than Array(...Array, ...Array). Depends on your use 
case. As for function composition, it's a matter of preference if A + B is 
supposed to mean (...args) => A(B(...args)) or rather (...args) => 
B(A(...args)).

My point is, as long as there is a statically analyzable definition for how 
operators are supposed to behave for a given set of input types, there's no 
reason not to give programmers the ability to provide such definitions.

But again, these discussions will be much more relevant if proposals such as 
[this one](https://github.com/sirisian/ecmascript-types) are discussed for 
standardization at some point.

On Saturday, February 3, 2018 4:57:34 AM CET Naveen Chawla wrote:
> I don't like the idea of custom operators only because of readability of
> code - it can be different for different pieces of code, and so I think it
> is a larger surface area for bugs, so I think it would be a net negative.
> 
> However, I do like the idea of allowing e.g. `+` to be used intuitively and
> consistently (i.e. with a fixed meaning) between certain data types that
> are not currently supported, e.g.:
> 
> Array + Array (array concatenation)
> Function + Function (function composition)
> 
> On Fri, 2 Feb 2018 at 22:02 Michael Haufe <t...@thenewobjective.com> wrote:
> > How would operator precedence work? Would we be restricted to 2-argument
> > functions only?
> > 
> > On Fri, Feb 2, 2018 at 5:55 AM, Thomas Grainger <tagr...@gmail.com> wrote:
> >> I'm porting this from the TypeScript issue tracker, original from:
> >> https://github.com/Microsoft/TypeScript/issues/2319#issue-60851953
> >> 
> >> Since it's very unlikely that the extension methods will ever be
> >> implemented [in a call-site-rewrite
> >> manner](
> >> https://github.com/Microsoft/TypeScript/issues/9#issuecomment-74302592),
> >> please consider adding infix operators to enable writing in functional
> >> style similarly to what can be done in Haskell:
> >> 
> >> Monoids
> >> 
> >> ```js
> >> 
> >> function '+' (left, right) {
> >> 
> >>return left.concat(right);
> >> 
> >> }
> >> 
> >> [1, 2, 3] '+' [4, 5]; // [1, 2, 3, 4, 5]
> >> 
> >> ```
> >> 
> >> Monads
> >> 
> >> ```js
> >> 
> >> function '>>=' (promise, bind) {
> >> 
> >>return promise.then(bind);
> >> 
> >> }
> >> $.get('/get') '>>=' x => $.post('/save', x + 1)
> >> 
> >> ```
> >> 
> >> Functors
> >> 
> >> ```js
> >> 
> >> function '.' (inner, outer) {
> >> 
> >>return function(value: a) : c {
> >>
> >>   return outer(inner(value))
> >>
> >>}
> >> 
> >> }
> >> 
> >> function f(x) { }
> >> function g(y) { }
> >> (f '.' g)(x); // z
> >> 
> >> ```
> >> 
> >> 
> >> 
> >> Thomas Grainger
> >> 
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> > 
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss

signature.asc
Description: This is a digitally signed message part.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Infix operators/functions

[Naveen Chawla]

I don't like the idea of custom operators only because of readability of
code - it can be different for different pieces of code, and so I think it
is a larger surface area for bugs, so I think it would be a net negative.

However, I do like the idea of allowing e.g. `+` to be used intuitively and
consistently (i.e. with a fixed meaning) between certain data types that
are not currently supported, e.g.:

Array + Array (array concatenation)
Function + Function (function composition)

On Fri, 2 Feb 2018 at 22:02 Michael Haufe <t...@thenewobjective.com> wrote:

> How would operator precedence work? Would we be restricted to 2-argument
> functions only?
>
>
>
> On Fri, Feb 2, 2018 at 5:55 AM, Thomas Grainger <tagr...@gmail.com> wrote:
>
>> I'm porting this from the TypeScript issue tracker, original from:
>> https://github.com/Microsoft/TypeScript/issues/2319#issue-60851953
>>
>> Since it's very unlikely that the extension methods will ever be
>> implemented [in a call-site-rewrite
>> manner](
>> https://github.com/Microsoft/TypeScript/issues/9#issuecomment-74302592),
>> please consider adding infix operators to enable writing in functional
>> style similarly to what can be done in Haskell:
>>
>> Monoids
>>
>> ```js
>>
>> function '+' (left, right) {
>>return left.concat(right);
>> }
>>
>> [1, 2, 3] '+' [4, 5]; // [1, 2, 3, 4, 5]
>>
>> ```
>>
>> Monads
>>
>> ```js
>> function '>>=' (promise, bind) {
>>return promise.then(bind);
>> }
>> $.get('/get') '>>=' x => $.post('/save', x + 1)
>> ```
>>
>> Functors
>>
>> ```js
>> function '.' (inner, outer) {
>>return function(value: a) : c {
>>   return outer(inner(value))
>>}
>> }
>>
>> function f(x) { }
>> function g(y) { }
>> (f '.' g)(x); // z
>> ```
>>
>>
>>
>> Thomas Grainger
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Infix operators/functions

[Michael Haufe]

How would operator precedence work? Would we be restricted to 2-argument
functions only?



On Fri, Feb 2, 2018 at 5:55 AM, Thomas Grainger <tagr...@gmail.com> wrote:

> I'm porting this from the TypeScript issue tracker, original from:
> https://github.com/Microsoft/TypeScript/issues/2319#issue-60851953
>
> Since it's very unlikely that the extension methods will ever be
> implemented [in a call-site-rewrite
> manner](https://github.com/Microsoft/TypeScript/issues/9#iss
> uecomment-74302592),
> please consider adding infix operators to enable writing in functional
> style similarly to what can be done in Haskell:
>
> Monoids
>
> ```js
>
> function '+' (left, right) {
>return left.concat(right);
> }
>
> [1, 2, 3] '+' [4, 5]; // [1, 2, 3, 4, 5]
>
> ```
>
> Monads
>
> ```js
> function '>>=' (promise, bind) {
>return promise.then(bind);
> }
> $.get('/get') '>>=' x => $.post('/save', x + 1)
> ```
>
> Functors
>
> ```js
> function '.' (inner, outer) {
>return function(value: a) : c {
>   return outer(inner(value))
>}
> }
>
> function f(x) { }
> function g(y) { }
> (f '.' g)(x); // z
> ```
>
>
>
> Thomas Grainger
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Infix operators/functions

[Mike Samuel]

On Fri, Feb 2, 2018 at 10:58 AM, Mike Samuel  wrote:

> How would this affect ASI?
>
> a  // no semicolon inserted since '+' is an infix operator
> +b
>
> a  // semicolon inserted since '!' is not an infix operator
> !b
>
> but what about
>
> function '!'(a, b) { ... }
> // now '!' is both an infix and a prefix operator
>
> a  // is a semicolon inserted?
> !b
>

The relevant portion of the spec is 11.9.1 Rules of Automatic Semicolon
Insertion

:
"""
   There are three basic rules of semicolon insertion:
   ...
   1. When, as a Script or Module is parsed from left to right, a token
(called the
   offending token) is encountered that *is not allowed by any
production* of the
  grammar, then a semicolon is automatically inserted before the
offending token
  if one or more of the following conditions is true:

  *  The offending token is separated from the previous token by at
least one
  LineTerminator.

 """
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Infix operators/functions

[Mike Samuel]

How would this affect ASI?

a  // no semicolon inserted since '+' is an infix operator
+b

a  // semicolon inserted since '!' is not an infix operator
!b

but what about

function '!'(a, b) { ... }
// now '!' is both an infix and a prefix operator

a  // is a semicolon inserted?
!b






On Fri, Feb 2, 2018 at 6:55 AM, Thomas Grainger <tagr...@gmail.com> wrote:

> I'm porting this from the TypeScript issue tracker, original from:
> https://github.com/Microsoft/TypeScript/issues/2319#issue-60851953
>
> Since it's very unlikely that the extension methods will ever be
> implemented [in a call-site-rewrite
> manner](https://github.com/Microsoft/TypeScript/issues/9#iss
> uecomment-74302592),
> please consider adding infix operators to enable writing in functional
> style similarly to what can be done in Haskell:
>
> Monoids
>
> ```js
>
> function '+' (left, right) {
>return left.concat(right);
> }
>
> [1, 2, 3] '+' [4, 5]; // [1, 2, 3, 4, 5]
>
> ```
>
> Monads
>
> ```js
> function '>>=' (promise, bind) {
>return promise.then(bind);
> }
> $.get('/get') '>>=' x => $.post('/save', x + 1)
> ```
>
> Functors
>
> ```js
> function '.' (inner, outer) {
>return function(value: a) : c {
>   return outer(inner(value))
>}
> }
>
> function f(x) { }
> function g(y) { }
> (f '.' g)(x); // z
> ```
>
>
>
> Thomas Grainger
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Infix operators/functions

[Isiah Meadows]

As it stands, I'd rather see operator overloading before custom operators.
In order to have decent custom operators, you really have to take into
account the whole grammar, and adding them in a way that's not a blatant
tack on usually involves rethinking the entire grammar. In contrast,
operator overloading only requires a rethink of the primitive object model,
and only analogous to how `instanceof` had to change to accommodate
`Symbol.hasInstance`.

On Fri, Feb 2, 2018, 07:07 kdex <k...@kdex.de> wrote:

> In ECMAScript's current state, infix operators would likely complicate
> future
> discussions of operator overloading. Before we tackle these problems, I
> think
> it's more convenient to have type annotations first.
>
> On Friday, February 2, 2018 12:55:17 PM CET Thomas Grainger wrote:
> > I'm porting this from the TypeScript issue tracker, original from:
> > https://github.com/Microsoft/TypeScript/issues/2319#issue-60851953
> >
> > Since it's very unlikely that the extension methods will ever be
> > implemented [in a call-site-rewrite
> > manner](https://github.com/Microsoft/TypeScript/issues/9#
> > issuecomment-74302592),
> > please consider adding infix operators to enable writing in functional
> > style similarly to what can be done in Haskell:
> >
> > Monoids
> >
> > ```js
> >
> > function '+' (left, right) {
> >return left.concat(right);
> > }
> >
> > [1, 2, 3] '+' [4, 5]; // [1, 2, 3, 4, 5]
> >
> > ```
> >
> > Monads
> >
> > ```js
> > function '>>=' (promise, bind) {
> >return promise.then(bind);
> > }
> > $.get('/get') '>>=' x => $.post('/save', x + 1)
> > ```
> >
> > Functors
> >
> > ```js
> > function '.' (inner, outer) {
> >return function(value: a) : c {
> >   return outer(inner(value))
> >}
> > }
> >
> > function f(x) { }
> > function g(y) { }
> > (f '.' g)(x); // z
> > ```
> >
> >
> >
> > Thomas Grainger___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Infix operators/functions

[kdex]

In ECMAScript's current state, infix operators would likely complicate future 
discussions of operator overloading. Before we tackle these problems, I think 
it's more convenient to have type annotations first.

On Friday, February 2, 2018 12:55:17 PM CET Thomas Grainger wrote:
> I'm porting this from the TypeScript issue tracker, original from:
> https://github.com/Microsoft/TypeScript/issues/2319#issue-60851953
> 
> Since it's very unlikely that the extension methods will ever be
> implemented [in a call-site-rewrite
> manner](https://github.com/Microsoft/TypeScript/issues/9#
> issuecomment-74302592),
> please consider adding infix operators to enable writing in functional
> style similarly to what can be done in Haskell:
> 
> Monoids
> 
> ```js
> 
> function '+' (left, right) {
>return left.concat(right);
> }
> 
> [1, 2, 3] '+' [4, 5]; // [1, 2, 3, 4, 5]
> 
> ```
> 
> Monads
> 
> ```js
> function '>>=' (promise, bind) {
>return promise.then(bind);
> }
> $.get('/get') '>>=' x => $.post('/save', x + 1)
> ```
> 
> Functors
> 
> ```js
> function '.' (inner, outer) {
>return function(value: a) : c {
>   return outer(inner(value))
>}
> }
> 
> function f(x) { }
> function g(y) { }
> (f '.' g)(x); // z
> ```
> 
> 
> 
> Thomas Grainger

signature.asc
Description: This is a digitally signed message part.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Suggestion: Infix operators/functions

[Thomas Grainger]

I'm porting this from the TypeScript issue tracker, original from:
https://github.com/Microsoft/TypeScript/issues/2319#issue-60851953

Since it's very unlikely that the extension methods will ever be
implemented [in a call-site-rewrite
manner](https://github.com/Microsoft/TypeScript/issues/9#
issuecomment-74302592),
please consider adding infix operators to enable writing in functional
style similarly to what can be done in Haskell:

Monoids

```js

function '+' (left, right) {
   return left.concat(right);
}

[1, 2, 3] '+' [4, 5]; // [1, 2, 3, 4, 5]

```

Monads

```js
function '>>=' (promise, bind) {
   return promise.then(bind);
}
$.get('/get') '>>=' x => $.post('/save', x + 1)
```

Functors

```js
function '.' (inner, outer) {
   return function(value: a) : c {
  return outer(inner(value))
   }
}

function f(x) { }
function g(y) { }
(f '.' g)(x); // z
```



Thomas Grainger
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Looking for Champion: Null Coalescing (??) and Null Conditional Member Access (?.) operators

[Ahmad Bamieh]

Thank you for this detailed write up! I believe you can help in the
existing proposals!

Cheers!
Ahmad Bamieh,

On Wed, Dec 20, 2017 at 10:18 AM, Arash Motamedi <arash.motam...@gmail.com>
wrote:

> Excellent! Thanks so much for the pointers. These will be great syntactic
> improvements.
>
> Cheers,
> Arash
>
> On Wed, Dec 20, 2017 at 12:12 AM, Claude Pache <claude.pa...@gmail.com>
> wrote:
>
>> There are already official proposals for those. See:
>>
>> https://github.com/tc39/proposals
>>
>> and search for “Nullish coalescing Operator” for the first of your
>> suggestions and “Optional Chaining” for the second one.
>>
>> —Claude
>>
>>
>>
>> Le 20 déc. 2017 à 09:03, Arash Motamedi <arash.motam...@gmail.com> a
>> écrit :
>>
>> I’d like to propose two new operators that I’ve appreciated using in C#,
>> with appropriate modifications for Ecmascript.
>>
>> ?? Null-Coalescing Operator
>>
>> The ?? operator is called the null-coalescing operator. It returns the
>>> left-hand operand if the operand is not null or undefined; otherwise it
>>> returns the right hand operand. (modified excerpt from C# definition,
>>> here
>>> <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator>
>>> .)
>>
>>
>> Examples:
>>
>> let u = undefined;
>> let nu = u ?? 0;
>> //  nu = (u !== undefined && u !== null) ? u : 0
>>
>> let n = null;
>> let nn = n ?? "Default";
>> //  nn = (n !== undefined && n !== null) ? n : "Default";
>>
>> let p = someObj.someProp ?? "Hello";
>> //  p = (someObj.someProp !== undefined && someObj.someProp !== null) ?
>> someObj.someProp : "Hello";
>>
>> The ?? operator allows for a very terse syntactic representation of a
>> rather common statement, and its value becomes very clear when evaluating
>> and accessing properties on objects, as illustrated in the 3rd example
>> above. For credit, comparison, and further details, please review the C#
>> null coalescing operator information here
>> <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator>
>> .
>>
>>
>> ?. Null Conditional Member Access and ?[ Null Conditional Index Access
>>
>> Used to test for null or undefined before performing a member access (?.)
>>> or index (?[) operation. (modified excerpt from C# definition here
>>> <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operators>
>>> .)
>>
>>
>> Examples:
>>
>> let n = null;
>> let nn = n?.name;
>> //  nn = (n.name !== null && u.name !== undefined) ? u.name : u.name;
>>
>> let p = {name: "John"};
>> let l = p.lastName?.length;
>> //  l = (u.lastName !== null && u.lastName !== undefined) ?
>> u.lastName.length : u.lastName;
>>
>> The ?. and ?[ operators allow for graceful access (as opposed to
>> null/undefined reference errors) to object members, and are particularly
>> useful when used in a chained manner. For credit, comparison, and further
>> details, please review the C# null conditional member access operator
>> information here
>> <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operators>
>> .
>>
>>
>> Combining the above operators can enable very concise syntax for checking
>> against null/undefined and providing default values in a graceful manner.
>>
>> let lastNameLength = person.lastName?.length ?? 0;
>> let cityToUppercase = person.address?.city?.toUpperCase() ?? "N/A";
>>
>>
>> Looking forward to working with the community and hopefully bringing
>> these two operators to the language.
>>
>> Best,
>> Arash
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Looking for Champion: Null Coalescing (??) and Null Conditional Member Access (?.) operators

[Arash Motamedi]

Excellent! Thanks so much for the pointers. These will be great syntactic
improvements.

Cheers,
Arash

On Wed, Dec 20, 2017 at 12:12 AM, Claude Pache <claude.pa...@gmail.com>
wrote:

> There are already official proposals for those. See:
>
> https://github.com/tc39/proposals
>
> and search for “Nullish coalescing Operator” for the first of your
> suggestions and “Optional Chaining” for the second one.
>
> —Claude
>
>
>
> Le 20 déc. 2017 à 09:03, Arash Motamedi <arash.motam...@gmail.com> a
> écrit :
>
> I’d like to propose two new operators that I’ve appreciated using in C#,
> with appropriate modifications for Ecmascript.
>
> ?? Null-Coalescing Operator
>
> The ?? operator is called the null-coalescing operator. It returns the
>> left-hand operand if the operand is not null or undefined; otherwise it
>> returns the right hand operand. (modified excerpt from C# definition,
>> here
>> <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator>
>> .)
>
>
> Examples:
>
> let u = undefined;
> let nu = u ?? 0;
> //  nu = (u !== undefined && u !== null) ? u : 0
>
> let n = null;
> let nn = n ?? "Default";
> //  nn = (n !== undefined && n !== null) ? n : "Default";
>
> let p = someObj.someProp ?? "Hello";
> //  p = (someObj.someProp !== undefined && someObj.someProp !== null) ?
> someObj.someProp : "Hello";
>
> The ?? operator allows for a very terse syntactic representation of a
> rather common statement, and its value becomes very clear when evaluating
> and accessing properties on objects, as illustrated in the 3rd example
> above. For credit, comparison, and further details, please review the C#
> null coalescing operator information here
> <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator>
> .
>
>
> ?. Null Conditional Member Access and ?[ Null Conditional Index Access
>
> Used to test for null or undefined before performing a member access (?.)
>> or index (?[) operation. (modified excerpt from C# definition here
>> <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operators>
>> .)
>
>
> Examples:
>
> let n = null;
> let nn = n?.name;
> //  nn = (n.name !== null && u.name !== undefined) ? u.name : u.name;
>
> let p = {name: "John"};
> let l = p.lastName?.length;
> //  l = (u.lastName !== null && u.lastName !== undefined) ?
> u.lastName.length : u.lastName;
>
> The ?. and ?[ operators allow for graceful access (as opposed to
> null/undefined reference errors) to object members, and are particularly
> useful when used in a chained manner. For credit, comparison, and further
> details, please review the C# null conditional member access operator
> information here
> <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operators>
> .
>
>
> Combining the above operators can enable very concise syntax for checking
> against null/undefined and providing default values in a graceful manner.
>
> let lastNameLength = person.lastName?.length ?? 0;
> let cityToUppercase = person.address?.city?.toUpperCase() ?? "N/A";
>
>
> Looking forward to working with the community and hopefully bringing these
> two operators to the language.
>
> Best,
> Arash
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Looking for Champion: Null Coalescing (??) and Null Conditional Member Access (?.) operators

[Claude Pache]

There are already official proposals for those. See:

https://github.com/tc39/proposals <https://github.com/tc39/proposals>

and search for “Nullish coalescing Operator” for the first of your suggestions 
and “Optional Chaining” for the second one.

—Claude



> Le 20 déc. 2017 à 09:03, Arash Motamedi <arash.motam...@gmail.com> a écrit :
> 
> I’d like to propose two new operators that I’ve appreciated using in C#, with 
> appropriate modifications for Ecmascript. 
> 
> ?? Null-Coalescing Operator
> 
> The ?? operator is called the null-coalescing operator. It returns the 
> left-hand operand if the operand is not null or undefined; otherwise it 
> returns the right hand operand. (modified excerpt from C# definition, here 
> <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator>.)
>   
> 
> Examples:
>  
> let u = undefined;
> let nu = u ?? 0; 
> //  nu = (u !== undefined && u !== null) ? u : 0
> 
> let n = null;
> let nn = n ?? "Default"; 
> //  nn = (n !== undefined && n !== null) ? n : "Default";
> 
> let p = someObj.someProp ?? "Hello"; 
> //  p = (someObj.someProp !== undefined && someObj.someProp !== null) ? 
> someObj.someProp : "Hello";
> 
> The ?? operator allows for a very terse syntactic representation of a rather 
> common statement, and its value becomes very clear when evaluating and 
> accessing properties on objects, as illustrated in the 3rd example above. For 
> credit, comparison, and further details, please review the C# null coalescing 
> operator information here 
> <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator>.
>  
> 
> 
> ?. Null Conditional Member Access and ?[ Null Conditional Index Access
> 
> Used to test for null or undefined before performing a member access (?.) or 
> index (?[) operation. (modified excerpt from C# definition here 
> <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operators>.)
>  
> 
> Examples:
>  
> let n = null;
> let nn = n?.name; 
> //  nn = (n.name <http://n.name/> !== null && u.name <http://u.name/> !== 
> undefined) ? u.name <http://u.name/> : u.name <http://u.name/>;
> 
> let p = {name: "John"};
> let l = p.lastName?.length; 
> //  l = (u.lastName !== null && u.lastName !== undefined) ? u.lastName.length 
> : u.lastName;
> 
> The ?. and ?[ operators allow for graceful access (as opposed to 
> null/undefined reference errors) to object members, and are particularly 
> useful when used in a chained manner. For credit, comparison, and further 
> details, please review the C# null conditional member access operator 
> information here 
> <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operators>.
>  
> 
> 
> Combining the above operators can enable very concise syntax for checking 
> against null/undefined and providing default values in a graceful manner. 
> 
> let lastNameLength = person.lastName?.length ?? 0; 
> let cityToUppercase = person.address?.city?.toUpperCase() ?? "N/A"; 
> 
> 
> Looking forward to working with the community and hopefully bringing these 
> two operators to the language. 
> 
> Best,
> Arash
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Looking for Champion: Null Coalescing (??) and Null Conditional Member Access (?.) operators

[Arash Motamedi]

I’d like to propose two new operators that I’ve appreciated using in C#,
with appropriate modifications for Ecmascript.

?? Null-Coalescing Operator

The ?? operator is called the null-coalescing operator. It returns the
> left-hand operand if the operand is not null or undefined; otherwise it
> returns the right hand operand. (modified excerpt from C# definition, here
> <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator>
> .)


Examples:

let u = undefined;
let nu = u ?? 0;
//  nu = (u !== undefined && u !== null) ? u : 0

let n = null;
let nn = n ?? "Default";
//  nn = (n !== undefined && n !== null) ? n : "Default";

let p = someObj.someProp ?? "Hello";
//  p = (someObj.someProp !== undefined && someObj.someProp !== null) ?
someObj.someProp : "Hello";

The ?? operator allows for a very terse syntactic representation of a
rather common statement, and its value becomes very clear when evaluating
and accessing properties on objects, as illustrated in the 3rd example
above. For credit, comparison, and further details, please review the C#
null coalescing operator information here
<https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator>
.


?. Null Conditional Member Access and ?[ Null Conditional Index Access

Used to test for null or undefined before performing a member access (?.)
> or index (?[) operation. (modified excerpt from C# definition here
> <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operators>
> .)


Examples:

let n = null;
let nn = n?.name;
//  nn = (n.name !== null && u.name !== undefined) ? u.name : u.name;

let p = {name: "John"};
let l = p.lastName?.length;
//  l = (u.lastName !== null && u.lastName !== undefined) ?
u.lastName.length : u.lastName;

The ?. and ?[ operators allow for graceful access (as opposed to
null/undefined reference errors) to object members, and are particularly
useful when used in a chained manner. For credit, comparison, and further
details, please review the C# null conditional member access operator
information here
<https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operators>
.


Combining the above operators can enable very concise syntax for checking
against null/undefined and providing default values in a graceful manner.

let lastNameLength = person.lastName?.length ?? 0;
let cityToUppercase = person.address?.city?.toUpperCase() ?? "N/A";


Looking forward to working with the community and hopefully bringing these
two operators to the language.

Best,
Arash
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Strict greater than, greater than or equal, less than and less than or equal comparison operators

[Oriol _]

See https://esdiscuss.org/topic/strict-relational-operators

--Oriol
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Strict greater than, greater than or equal, less than and less than or equal comparison operators

[Bouke Scheurwater]

To be able to fully compare number operands with type checking,
wouldn't it be nice to have:

Strict greater than ( >== )
Strict greater than or equal ( >=== )
Strict less than ( <== )
and Stricht less than or equal ( <=== )

comparison operators which also check for type?

We'd avoid having to deal with cases like:

null > 0; // false
null == 0; // false
null >= 0; // true
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Re: Functional Operators

[doodad-js Admin]

One question I have: why all these fuzzy (sorry, functional) operators? That
could become very hard to know what the code exactly does, and difficult to
debug... Are you becoming too "lazy" to type on the keyboard?

 

 

From: Ron Buckton [mailto:ron.buck...@microsoft.com] 
Sent: Sunday, 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 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: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 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.buck...@microsoft.com
<mailto:ron.buck...@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-boun...@mozilla.org
<mailto:es-discuss-boun...@mozilla.org> ] On Behalf Of Darien Valentine
Sent: Monday, July 10, 2017 3:08 PM
To: es-discuss@mozilla.org <mailto: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

RE: Re: Functional Operators

[Ron Buckton]

(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: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 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.buck...@microsoft.com<mailto:ron.buck...@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-boun...@mozilla.org<mailto:es-discuss-boun...@mozilla.org>] 
On Behalf Of Darien Valentine
Sent: Monday, July 10, 2017 3:08 PM
To: es-discuss@mozilla.org<mailto: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

Re: Re: Functional Operators

[Darien Valentine]

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.buck...@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-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

RE: Re: Functional Operators

[Ron Buckton]

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

Re: Functional Operators

[Isiah Meadows]

+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 `-` could be either unary or binary, and `x => -x` and `(a,
b) => a - b` are both valid potential desugarings. Similar issues exist for
`+`.

On Tue, Jul 11, 2017, 07:15 kai zhu <kaizhu...@gmail.com> wrote:

> -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" <cont...@vihan.org> wrote:
>
>> As JS/ECMAScript gains more and more of a functional use, I've been
>> really wanting a functional operator feature from JS for a while. If you
>> aren't familiar with them, they are inspired from haskell along the lines
>> of:
>>
>> ```js
>> let add1 = (+);  // This is the same as below
>> let add2 = (a, b) => a + b;
>> ```
>>
>> This definitely helps clear up verbosity in reduce statements and related
>> functions. Another example would be for sorting:
>>
>> ```js
>> [1,4,3,6].sort((-));
>> ```
>>
>> While all operators (namely `=`) wouldn't work as functional operators, I
>> think this would be a useful addition to the language.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Functional Operators

[kai zhu]

-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" <cont...@vihan.org> wrote:

> As JS/ECMAScript gains more and more of a functional use, I've been really
> wanting a functional operator feature from JS for a while. If you aren't
> familiar with them, they are inspired from haskell along the lines of:
>
> ```js
> let add1 = (+);  // This is the same as below
> let add2 = (a, b) => a + b;
> ```
>
> This definitely helps clear up verbosity in reduce statements and related
> functions. Another example would be for sorting:
>
> ```js
> [1,4,3,6].sort((-));
> ```
>
> While all operators (namely `=`) wouldn't work as functional operators, I
> think this would be a useful addition to the language.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Functional Operators

[Darien Valentine]

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

Functional Operators

[Vihan Bhargava]

As JS/ECMAScript gains more and more of a functional use, I've been really 
wanting a functional operator feature from JS for a while. If you aren't 
familiar with them, they are inspired from haskell along the lines of:

```js
let add1 = (+);  // This is the same as below
let add2 = (a, b) => a + b;
```

This definitely helps clear up verbosity in reduce statements and related 
functions. Another example would be for sorting:

```js
[1,4,3,6].sort((-));
```

While all operators (namely `=`) wouldn't work as functional operators, I think 
this would be a useful addition to the language.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Overloading an operators

[Patrik Šimunič]

I hit on this topic while experimenting with imaginary numbers and although 
this subject was once already declined as proposal to ECMAScript 4, I would 
like to open it again. In a recent years ECMAScript has grown, a lot of 
application logic has moved from server to client and because ECMAScript is and 
(at least in a near future) will be the only major language for handling 
application logic in the client, it is essential that ECMAScript has to grow 
into more complex and capable language as we need it to handle more complex 
tasks.

One concrete way is adding an operators overloading feature. Imaginary numbers 
might not be the best example, so lets try to imagine more likely example, eg. 
vectors. When writing a module to deal with a vector graphic, you need a way to 
implement an operations with vectors. In most scenarios, it would be much 
easier for developers to define their own implementation of operators 
specifically for their scope - module.

Programming is very tightly related to math, we need a bit more robust language 
for dealing with more math related problems - this involves vectors, imaginary 
numbers, matrices, intervals and may other mathematical concepts.
Since ECMAScript is currently the only cross-platform, natively supported 
language to write applications on client (I purposely don’t mention server side 
ECMAScript, because on this field you can argue, that there are other possible 
ways to go - from C# and Java to Go), it eventually has to grow to capability 
of performing most task that are in common server-side/programming languages 
possible.

Overloading an operators is just one way to get closer to this goal.

I am looking forward to your opinions, ideas and notes on this matter.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Re: Strict Relational Operators

[Matthew Robb]

Also there was once the is/isnt operators and they lasted in ES6 for a very
long time and went pulled for reasons like this.

On Apr 15, 2017 4:06 AM, "Isiah Meadows" <isiahmead...@gmail.com> wrote:

> Okay, I stand corrected... (I forgot about those)
>
> On Sat, Apr 15, 2017, 04:01 Jordan Harband <ljh...@gmail.com> wrote:
>
>> There's also `instanceof`.
>>
>> On Fri, Apr 14, 2017 at 11:31 PM, T.J. Crowder <
>> tj.crow...@farsightsoftware.com> wrote:
>>
>>> Happy with `neq`.
>>>
>>> > Up to date, the only keyword
>>> > operators have been exclusively unary, such as `typeof`, `await`,
>>> > and `yield`.
>>>
>>> Not quite. :-) As I mentioned when suggesting them originally, there is
>>> *one* binary non-symbolic operator already: `in`
>>>
>>> ```js
>>> if ("foo" in obj)
>>> ```
>>>
>>> So the concept of non-symbolic binary operators isn't entirely new to
>>> the parsing/grammar infrastructure.
>>>
>>> -- T.J. Crowder
>>>
>>> On Sat, Apr 15, 2017 at 4:42 AM, Isiah Meadows <isiahmead...@gmail.com>
>>> wrote:
>>>
>>>> So far, the only decent proposal I've seen here is the keyword
>>>> operator idea. It looks operator-y, and it actually reads like what
>>>> you expect. Few nits about the general idea, and most of these would
>>>> probably keep TC39 from considering them:
>>>>
>>>> 1. `neq` is better than `noteq`. 2 fewer characters for a common
>>>> operation.
>>>>
>>>> 2. JS is a weakly typed language, and coerces nearly everything. It
>>>> normally calls `.valueOf()` (if it exists) and coerces the result to
>>>> numbers for the comparison operators. Strong type checking has
>>>> generally only been reserved for scenarios that can't be optimized
>>>> well otherwise (like the length of typed arrays) or that require
>>>> specific guarantees that coercion prevents (like uniqueness for weak
>>>> collections).
>>>>
>>>> 3. TypeScript and Flow both literally don't have this issue at all,
>>>> and several members of TC39 actively use these in mission-critical
>>>> code.
>>>>
>>>> 4. JS has historically *avoided* keyword operators, electing to remain
>>>> close-ish to its curly brace and punctuation-driven roots. Consider
>>>> `=>`, `&&` and `||`, `function *`, etc. Up to date, the only keyword
>>>> operators have been exclusively unary, such as `typeof`, `await`, and
>>>> `yield`. So this would face a potentially steep slope to acceptance.
>>>>
>>>> Just a bit of pessimistic pragmatism here.
>>>> -
>>>>
>>>> Isiah Meadows
>>>> m...@isiahmeadows.com
>>>>
>>>>
>>>> On Fri, Apr 14, 2017 at 5:33 PM, doodad-js Admin <dooda...@gmail.com>
>>>> wrote:
>>>> > I prefer the idea of keyword operators, like :
>>>> >
>>>> >
>>>> >
>>>> > a lt 1 // strict < 1
>>>> >
>>>> > a lte 1 // strict <=1
>>>> >
>>>> > a gt 1 // strict > 1
>>>> >
>>>> > a gte 1 // strict >= 1
>>>> >
>>>> > ...
>>>> >
>>>> >
>>>> >
>>>> > That’s easier to understand and memorize.
>>>> >
>>>> >
>>>> >
>>>> > From: Dawid Szlachta [mailto:dawidmj.szlac...@gmail.com]
>>>> > Sent: Friday, April 14, 2017 5:12 AM
>>>> > To: Jordan Harband <ljh...@gmail.com>
>>>> > Cc: es-discuss <es-discuss@mozilla.org>
>>>> > Subject: Re: Re: Strict Relational Operators
>>>> >
>>>> >
>>>> >
>>>> > [...]
>>>> >
>>>> >
>>>> >
>>>> > The =@=@= operator is probably easier to add and won't break the web.
>>>> Also,
>>>> > some basic pattern matching for functions would be useful and time
>>>> saving
>>>> > feature:
>>>> >
>>>> >
>>>> >
>>>> > [...]
>>>> >
>>>> >
>>>> > ___
>>>> > es-discuss mailing list
>>>> > es-discuss@mozilla.org
>>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>> >
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Re: Strict Relational Operators

[Isiah Meadows]

Okay, I stand corrected... (I forgot about those)

On Sat, Apr 15, 2017, 04:01 Jordan Harband <ljh...@gmail.com> wrote:

> There's also `instanceof`.
>
> On Fri, Apr 14, 2017 at 11:31 PM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>
>> Happy with `neq`.
>>
>> > Up to date, the only keyword
>> > operators have been exclusively unary, such as `typeof`, `await`,
>> > and `yield`.
>>
>> Not quite. :-) As I mentioned when suggesting them originally, there is
>> *one* binary non-symbolic operator already: `in`
>>
>> ```js
>> if ("foo" in obj)
>> ```
>>
>> So the concept of non-symbolic binary operators isn't entirely new to the
>> parsing/grammar infrastructure.
>>
>> -- T.J. Crowder
>>
>> On Sat, Apr 15, 2017 at 4:42 AM, Isiah Meadows <isiahmead...@gmail.com>
>> wrote:
>>
>>> So far, the only decent proposal I've seen here is the keyword
>>> operator idea. It looks operator-y, and it actually reads like what
>>> you expect. Few nits about the general idea, and most of these would
>>> probably keep TC39 from considering them:
>>>
>>> 1. `neq` is better than `noteq`. 2 fewer characters for a common
>>> operation.
>>>
>>> 2. JS is a weakly typed language, and coerces nearly everything. It
>>> normally calls `.valueOf()` (if it exists) and coerces the result to
>>> numbers for the comparison operators. Strong type checking has
>>> generally only been reserved for scenarios that can't be optimized
>>> well otherwise (like the length of typed arrays) or that require
>>> specific guarantees that coercion prevents (like uniqueness for weak
>>> collections).
>>>
>>> 3. TypeScript and Flow both literally don't have this issue at all,
>>> and several members of TC39 actively use these in mission-critical
>>> code.
>>>
>>> 4. JS has historically *avoided* keyword operators, electing to remain
>>> close-ish to its curly brace and punctuation-driven roots. Consider
>>> `=>`, `&&` and `||`, `function *`, etc. Up to date, the only keyword
>>> operators have been exclusively unary, such as `typeof`, `await`, and
>>> `yield`. So this would face a potentially steep slope to acceptance.
>>>
>>> Just a bit of pessimistic pragmatism here.
>>> -
>>>
>>> Isiah Meadows
>>> m...@isiahmeadows.com
>>>
>>>
>>> On Fri, Apr 14, 2017 at 5:33 PM, doodad-js Admin <dooda...@gmail.com>
>>> wrote:
>>> > I prefer the idea of keyword operators, like :
>>> >
>>> >
>>> >
>>> > a lt 1 // strict < 1
>>> >
>>> > a lte 1 // strict <=1
>>> >
>>> > a gt 1 // strict > 1
>>> >
>>> > a gte 1 // strict >= 1
>>> >
>>> > ...
>>> >
>>> >
>>> >
>>> > That’s easier to understand and memorize.
>>> >
>>> >
>>> >
>>> > From: Dawid Szlachta [mailto:dawidmj.szlac...@gmail.com]
>>> > Sent: Friday, April 14, 2017 5:12 AM
>>> > To: Jordan Harband <ljh...@gmail.com>
>>> > Cc: es-discuss <es-discuss@mozilla.org>
>>> > Subject: Re: Re: Strict Relational Operators
>>> >
>>> >
>>> >
>>> > [...]
>>> >
>>> >
>>> >
>>> > The =@=@= operator is probably easier to add and won't break the web.
>>> Also,
>>> > some basic pattern matching for functions would be useful and time
>>> saving
>>> > feature:
>>> >
>>> >
>>> >
>>> > [...]
>>> >
>>> >
>>> > ___
>>> > es-discuss mailing list
>>> > es-discuss@mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Re: Strict Relational Operators

[Jordan Harband]

There's also `instanceof`.

On Fri, Apr 14, 2017 at 11:31 PM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> Happy with `neq`.
>
> > Up to date, the only keyword
> > operators have been exclusively unary, such as `typeof`, `await`,
> > and `yield`.
>
> Not quite. :-) As I mentioned when suggesting them originally, there is
> *one* binary non-symbolic operator already: `in`
>
> ```js
> if ("foo" in obj)
> ```
>
> So the concept of non-symbolic binary operators isn't entirely new to the
> parsing/grammar infrastructure.
>
> -- T.J. Crowder
>
> On Sat, Apr 15, 2017 at 4:42 AM, Isiah Meadows <isiahmead...@gmail.com>
> wrote:
>
>> So far, the only decent proposal I've seen here is the keyword
>> operator idea. It looks operator-y, and it actually reads like what
>> you expect. Few nits about the general idea, and most of these would
>> probably keep TC39 from considering them:
>>
>> 1. `neq` is better than `noteq`. 2 fewer characters for a common
>> operation.
>>
>> 2. JS is a weakly typed language, and coerces nearly everything. It
>> normally calls `.valueOf()` (if it exists) and coerces the result to
>> numbers for the comparison operators. Strong type checking has
>> generally only been reserved for scenarios that can't be optimized
>> well otherwise (like the length of typed arrays) or that require
>> specific guarantees that coercion prevents (like uniqueness for weak
>> collections).
>>
>> 3. TypeScript and Flow both literally don't have this issue at all,
>> and several members of TC39 actively use these in mission-critical
>> code.
>>
>> 4. JS has historically *avoided* keyword operators, electing to remain
>> close-ish to its curly brace and punctuation-driven roots. Consider
>> `=>`, `&&` and `||`, `function *`, etc. Up to date, the only keyword
>> operators have been exclusively unary, such as `typeof`, `await`, and
>> `yield`. So this would face a potentially steep slope to acceptance.
>>
>> Just a bit of pessimistic pragmatism here.
>> -
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>>
>>
>> On Fri, Apr 14, 2017 at 5:33 PM, doodad-js Admin <dooda...@gmail.com>
>> wrote:
>> > I prefer the idea of keyword operators, like :
>> >
>> >
>> >
>> > a lt 1 // strict < 1
>> >
>> > a lte 1 // strict <=1
>> >
>> > a gt 1 // strict > 1
>> >
>> > a gte 1 // strict >= 1
>> >
>> > ...
>> >
>> >
>> >
>> > That’s easier to understand and memorize.
>> >
>> >
>> >
>> > From: Dawid Szlachta [mailto:dawidmj.szlac...@gmail.com]
>> > Sent: Friday, April 14, 2017 5:12 AM
>> > To: Jordan Harband <ljh...@gmail.com>
>> > Cc: es-discuss <es-discuss@mozilla.org>
>> > Subject: Re: Re: Strict Relational Operators
>> >
>> >
>> >
>> > [...]
>> >
>> >
>> >
>> > The =@=@= operator is probably easier to add and won't break the web.
>> Also,
>> > some basic pattern matching for functions would be useful and time
>> saving
>> > feature:
>> >
>> >
>> >
>> > [...]
>> >
>> >
>> > ___
>> > es-discuss mailing list
>> > es-discuss@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Re: Strict Relational Operators

[T.J. Crowder]

Happy with `neq`.

> Up to date, the only keyword
> operators have been exclusively unary, such as `typeof`, `await`,
> and `yield`.

Not quite. :-) As I mentioned when suggesting them originally, there is
*one* binary non-symbolic operator already: `in`

```js
if ("foo" in obj)
```

So the concept of non-symbolic binary operators isn't entirely new to the
parsing/grammar infrastructure.

-- T.J. Crowder

On Sat, Apr 15, 2017 at 4:42 AM, Isiah Meadows <isiahmead...@gmail.com>
wrote:

> So far, the only decent proposal I've seen here is the keyword
> operator idea. It looks operator-y, and it actually reads like what
> you expect. Few nits about the general idea, and most of these would
> probably keep TC39 from considering them:
>
> 1. `neq` is better than `noteq`. 2 fewer characters for a common operation.
>
> 2. JS is a weakly typed language, and coerces nearly everything. It
> normally calls `.valueOf()` (if it exists) and coerces the result to
> numbers for the comparison operators. Strong type checking has
> generally only been reserved for scenarios that can't be optimized
> well otherwise (like the length of typed arrays) or that require
> specific guarantees that coercion prevents (like uniqueness for weak
> collections).
>
> 3. TypeScript and Flow both literally don't have this issue at all,
> and several members of TC39 actively use these in mission-critical
> code.
>
> 4. JS has historically *avoided* keyword operators, electing to remain
> close-ish to its curly brace and punctuation-driven roots. Consider
> `=>`, `&&` and `||`, `function *`, etc. Up to date, the only keyword
> operators have been exclusively unary, such as `typeof`, `await`, and
> `yield`. So this would face a potentially steep slope to acceptance.
>
> Just a bit of pessimistic pragmatism here.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
>
> On Fri, Apr 14, 2017 at 5:33 PM, doodad-js Admin <dooda...@gmail.com>
> wrote:
> > I prefer the idea of keyword operators, like :
> >
> >
> >
> > a lt 1 // strict < 1
> >
> > a lte 1 // strict <=1
> >
> > a gt 1 // strict > 1
> >
> > a gte 1 // strict >= 1
> >
> > ...
> >
> >
> >
> > That’s easier to understand and memorize.
> >
> >
> >
> > From: Dawid Szlachta [mailto:dawidmj.szlac...@gmail.com]
> > Sent: Friday, April 14, 2017 5:12 AM
> > To: Jordan Harband <ljh...@gmail.com>
> > Cc: es-discuss <es-discuss@mozilla.org>
> > Subject: Re: Re: Strict Relational Operators
> >
> >
> >
> > [...]
> >
> >
> >
> > The =@=@= operator is probably easier to add and won't break the web.
> Also,
> > some basic pattern matching for functions would be useful and time saving
> > feature:
> >
> >
> >
> > [...]
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Re: Strict Relational Operators

[Isiah Meadows]

So far, the only decent proposal I've seen here is the keyword
operator idea. It looks operator-y, and it actually reads like what
you expect. Few nits about the general idea, and most of these would
probably keep TC39 from considering them:

1. `neq` is better than `noteq`. 2 fewer characters for a common operation.

2. JS is a weakly typed language, and coerces nearly everything. It
normally calls `.valueOf()` (if it exists) and coerces the result to
numbers for the comparison operators. Strong type checking has
generally only been reserved for scenarios that can't be optimized
well otherwise (like the length of typed arrays) or that require
specific guarantees that coercion prevents (like uniqueness for weak
collections).

3. TypeScript and Flow both literally don't have this issue at all,
and several members of TC39 actively use these in mission-critical
code.

4. JS has historically *avoided* keyword operators, electing to remain
close-ish to its curly brace and punctuation-driven roots. Consider
`=>`, `&&` and `||`, `function *`, etc. Up to date, the only keyword
operators have been exclusively unary, such as `typeof`, `await`, and
`yield`. So this would face a potentially steep slope to acceptance.

Just a bit of pessimistic pragmatism here.
-

Isiah Meadows
m...@isiahmeadows.com


On Fri, Apr 14, 2017 at 5:33 PM, doodad-js Admin <dooda...@gmail.com> wrote:
> I prefer the idea of keyword operators, like :
>
>
>
> a lt 1 // strict < 1
>
> a lte 1 // strict <=1
>
> a gt 1 // strict > 1
>
> a gte 1 // strict >= 1
>
> ...
>
>
>
> That’s easier to understand and memorize.
>
>
>
> From: Dawid Szlachta [mailto:dawidmj.szlac...@gmail.com]
> Sent: Friday, April 14, 2017 5:12 AM
> To: Jordan Harband <ljh...@gmail.com>
> Cc: es-discuss <es-discuss@mozilla.org>
> Subject: Re: Re: Strict Relational Operators
>
>
>
> [...]
>
>
>
> The =@=@= operator is probably easier to add and won't break the web. Also,
> some basic pattern matching for functions would be useful and time saving
> feature:
>
>
>
> [...]
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

FW: Re: Strict Relational Operators

[doodad-js Admin]

I prefer the idea of keyword operators, like :

 

a lt 1 // strict < 1

a lte 1 // strict <=1

a gt 1 // strict > 1

a gte 1 // strict >= 1

...

 

That’s easier to understand and memorize.

 

From: Dawid Szlachta [mailto:dawidmj.szlac...@gmail.com] 
Sent: Friday, April 14, 2017 5:12 AM
To: Jordan Harband <ljh...@gmail.com <mailto:ljh...@gmail.com> >
Cc: es-discuss <es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> >
Subject: Re: Re: Strict Relational Operators

 

[...]

 

The =@=@= operator is probably easier to add and won't break the web. Also, 
some basic pattern matching for functions would be useful and time saving 
feature:

 

[...]

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Strict Relational Operators

[Dawid Szlachta]

Well, I think we won't see type system in ES anytime soon, as 1) it is a
huge design process and discussion; 2) part of the committee seems to be
against type system in the language (I can remember such statement written
on this list by someone from TC39).

The =@=@= operator is probably easier to add and won't break the web. Also,
some basic pattern matching for functions would be useful and time saving
feature:

```
function setClientName(name)
  given String { client.name = name }
  given * { throw "Name should be a string" }
```

Dawid

2017-04-14 2:15 GMT+02:00 Jordan Harband <ljh...@gmail.com>:

> Perhaps a simpler approach (short of type systems) would be a single
> binary operator that returned true only when the Type() of each operand was
> the same?
>
> In other words (using "=@=@=" to avoid bikeshedding on the syntax itself):
>
> `a =@=@= b` would be equivalent to `(a === null || b === null) ? (a ===
> null && b === null) : typeof a === typeof b` - then you could use the
> operator to explicitly guard any comparison operators where you wanted the
> type to be the same, and throw, return false, or coerce to your heart's
> content.
>
> On Thu, Apr 13, 2017 at 5:35 AM, James Treworgy <jamie...@gmail.com>
> wrote:
>
>> That would seem to make more sense. At the end of the day, for me, I just
>> don't much value in adding new syntax for operators to do this. The only
>> time I can think of in my own code where this would be useful (in the sense
>> that it would have avoided some extra type check to ensure things work as I
>> want) is evaluating >= 0, where the current Javascript behavior is
>> unfortunate:
>>
>> *null >= 0 // true*
>> *undefined >= 0 // false*
>>
>> But for most situations, it doesn't help much, you still need to do a
>> manual type check to avoid unexpected behavior. If I'm comparing a counter
>> to a limit, a loop might just run forever. If I'm comparing one thing to
>> another for sorting, it just puts all non-typed things first. The behavior
>> of many things will be different, but unlikely better. It doesn't help you
>> write code that avoids unwanted code paths.
>>
>> I also feel like the problem of "are a and b of the same type, and is a
>> greater than/less than b" is very easily solved with a helper:
>>
>>
>> *if (strict.gt <http://strict.gt>(a, v)) {  }*
>> *if (strict.lt <http://strict.lt>(a, b)) { }*
>>
>> What we REALLY need is runtime type checking. I write lots of code like
>> this (or using helpers to accomplish the same with less boilerplate) in
>> public APIs:
>>
>> *function(a, b) {*
>> *assert.ok(typeof a === 'number')*
>> *assert.ok(typeof b === 'string')*
>> *...*
>> *}*
>>
>> I don't see why we can't have a flow-like syntax that is syntactic sugar
>> for this:
>>
>> *function(a: string, b: number) {*
>> *   let c: string[] = [a, 'foo']*
>> *}*
>>
>> Yeah - different discussion - but I feel like addding indirect ways to
>> check types with new expression or operator syntax, rather than just
>> addressing the problem head-on by allowing runtime type checking at
>> variable declaration & function invocation time, is just going to further
>> confuse matters and make code quality and readibility worse, not better.
>>
>>
>>
>>
>>
>>
>> On Thu, Apr 13, 2017 at 8:04 AM, T.J. Crowder <
>> tj.crow...@farsightsoftware.com> wrote:
>>
>>> Yeah. I suggested that if we aren't doing symbolic operators but rather
>>> functions or something else, they should result in `undefined` for mixed
>>> types, so you can differentiate if appropriate. (Symbolic operators like
>>> `<=<` would need to be consistent with `===` and `!==`, though, which
>>> don't, sadly, do that; and that won't be changing. :-) ) Functions or
>>> non-symbolic operators would have the option of doing that, or throwing,
>>> whatever people end up thinking is best.
>>>
>>> -- T.J. Crowder
>>>
>>> On Thu, Apr 13, 2017 at 12:41 PM, James Treworgy <jamie...@gmail.com>
>>> wrote:
>>>
>>>> Put another way  === is useful because you test for strict equality.
>>>> Either it is or is not what you need. But always returning false when
>>>> comparing things with less than or greater than doesn't ensure that you got
>>>> what you want. A false value can be success as much as a true value.
>>>>
>>>> On Apr 13, 2017 7:37 AM, "James Treworgy" <jamie

Re: Re: Strict Relational Operators

[Jordan Harband]

Perhaps a simpler approach (short of type systems) would be a single binary
operator that returned true only when the Type() of each operand was the
same?

In other words (using "=@=@=" to avoid bikeshedding on the syntax itself):

`a =@=@= b` would be equivalent to `(a === null || b === null) ? (a ===
null && b === null) : typeof a === typeof b` - then you could use the
operator to explicitly guard any comparison operators where you wanted the
type to be the same, and throw, return false, or coerce to your heart's
content.

On Thu, Apr 13, 2017 at 5:35 AM, James Treworgy <jamie...@gmail.com> wrote:

> That would seem to make more sense. At the end of the day, for me, I just
> don't much value in adding new syntax for operators to do this. The only
> time I can think of in my own code where this would be useful (in the sense
> that it would have avoided some extra type check to ensure things work as I
> want) is evaluating >= 0, where the current Javascript behavior is
> unfortunate:
>
> *null >= 0 // true*
> *undefined >= 0 // false*
>
> But for most situations, it doesn't help much, you still need to do a
> manual type check to avoid unexpected behavior. If I'm comparing a counter
> to a limit, a loop might just run forever. If I'm comparing one thing to
> another for sorting, it just puts all non-typed things first. The behavior
> of many things will be different, but unlikely better. It doesn't help you
> write code that avoids unwanted code paths.
>
> I also feel like the problem of "are a and b of the same type, and is a
> greater than/less than b" is very easily solved with a helper:
>
>
> *if (strict.gt <http://strict.gt>(a, v)) {  }*
> *if (strict.lt <http://strict.lt>(a, b)) { }*
>
> What we REALLY need is runtime type checking. I write lots of code like
> this (or using helpers to accomplish the same with less boilerplate) in
> public APIs:
>
> *function(a, b) {*
> *assert.ok(typeof a === 'number')*
> *assert.ok(typeof b === 'string')*
> *...*
> *}*
>
> I don't see why we can't have a flow-like syntax that is syntactic sugar
> for this:
>
> *function(a: string, b: number) {*
> *   let c: string[] = [a, 'foo']*
> *}*
>
> Yeah - different discussion - but I feel like addding indirect ways to
> check types with new expression or operator syntax, rather than just
> addressing the problem head-on by allowing runtime type checking at
> variable declaration & function invocation time, is just going to further
> confuse matters and make code quality and readibility worse, not better.
>
>
>
>
>
>
> On Thu, Apr 13, 2017 at 8:04 AM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>
>> Yeah. I suggested that if we aren't doing symbolic operators but rather
>> functions or something else, they should result in `undefined` for mixed
>> types, so you can differentiate if appropriate. (Symbolic operators like
>> `<=<` would need to be consistent with `===` and `!==`, though, which
>> don't, sadly, do that; and that won't be changing. :-) ) Functions or
>> non-symbolic operators would have the option of doing that, or throwing,
>> whatever people end up thinking is best.
>>
>> -- T.J. Crowder
>>
>> On Thu, Apr 13, 2017 at 12:41 PM, James Treworgy <jamie...@gmail.com>
>> wrote:
>>
>>> Put another way  === is useful because you test for strict equality.
>>> Either it is or is not what you need. But always returning false when
>>> comparing things with less than or greater than doesn't ensure that you got
>>> what you want. A false value can be success as much as a true value.
>>>
>>> On Apr 13, 2017 7:37 AM, "James Treworgy" <jamie...@gmail.com> wrote:
>>>
>>>> Strict expressions. In the case of always returning false, that seems
>>>> like little help in avoiding bugs to me, since code flow always 
>>>> continues...
>>>>
>>>> On Apr 13, 2017 7:35 AM, "T.J. Crowder" <tj.crowder@farsightsoftware.c
>>>> om> wrote:
>>>>
>>>>> James, are you commenting on felix's idea of strict expressions (in
>>>>> which case, I suggest the other thread: https://esdiscuss.org/topic/st
>>>>> rict-non-coercing-expressions), or strict relational operators?
>>>>>
>>>>> Other than felix's strict expressions, I don't think anyone was
>>>>> suggesting that strict relational operators should throw. It would be
>>>>> important that they behave consistently with `===` and `!==`: Just result
>>>>> in `false`

Re: Re: Strict Relational Operators

[James Treworgy]

That would seem to make more sense. At the end of the day, for me, I just
don't much value in adding new syntax for operators to do this. The only
time I can think of in my own code where this would be useful (in the sense
that it would have avoided some extra type check to ensure things work as I
want) is evaluating >= 0, where the current Javascript behavior is
unfortunate:

*null >= 0 // true*
*undefined >= 0 // false*

But for most situations, it doesn't help much, you still need to do a
manual type check to avoid unexpected behavior. If I'm comparing a counter
to a limit, a loop might just run forever. If I'm comparing one thing to
another for sorting, it just puts all non-typed things first. The behavior
of many things will be different, but unlikely better. It doesn't help you
write code that avoids unwanted code paths.

I also feel like the problem of "are a and b of the same type, and is a
greater than/less than b" is very easily solved with a helper:


*if (strict.gt <http://strict.gt>(a, v)) {  }*
*if (strict.lt <http://strict.lt>(a, b)) { }*

What we REALLY need is runtime type checking. I write lots of code like
this (or using helpers to accomplish the same with less boilerplate) in
public APIs:

*function(a, b) {*
*assert.ok(typeof a === 'number')*
*assert.ok(typeof b === 'string')*
*...*
*}*

I don't see why we can't have a flow-like syntax that is syntactic sugar
for this:

*function(a: string, b: number) {*
*   let c: string[] = [a, 'foo']*
*}*

Yeah - different discussion - but I feel like addding indirect ways to
check types with new expression or operator syntax, rather than just
addressing the problem head-on by allowing runtime type checking at
variable declaration & function invocation time, is just going to further
confuse matters and make code quality and readibility worse, not better.






On Thu, Apr 13, 2017 at 8:04 AM, T.J. Crowder <tj.crowder@farsightsoftware.c
om> wrote:

> Yeah. I suggested that if we aren't doing symbolic operators but rather
> functions or something else, they should result in `undefined` for mixed
> types, so you can differentiate if appropriate. (Symbolic operators like
> `<=<` would need to be consistent with `===` and `!==`, though, which
> don't, sadly, do that; and that won't be changing. :-) ) Functions or
> non-symbolic operators would have the option of doing that, or throwing,
> whatever people end up thinking is best.
>
> -- T.J. Crowder
>
> On Thu, Apr 13, 2017 at 12:41 PM, James Treworgy <jamie...@gmail.com>
> wrote:
>
>> Put another way  === is useful because you test for strict equality.
>> Either it is or is not what you need. But always returning false when
>> comparing things with less than or greater than doesn't ensure that you got
>> what you want. A false value can be success as much as a true value.
>>
>> On Apr 13, 2017 7:37 AM, "James Treworgy" <jamie...@gmail.com> wrote:
>>
>>> Strict expressions. In the case of always returning false, that seems
>>> like little help in avoiding bugs to me, since code flow always continues...
>>>
>>> On Apr 13, 2017 7:35 AM, "T.J. Crowder" <tj.crow...@farsightsoftware.com>
>>> wrote:
>>>
>>>> James, are you commenting on felix's idea of strict expressions (in
>>>> which case, I suggest the other thread: https://esdiscuss.org/topic/st
>>>> rict-non-coercing-expressions), or strict relational operators?
>>>>
>>>> Other than felix's strict expressions, I don't think anyone was
>>>> suggesting that strict relational operators should throw. It would be
>>>> important that they behave consistently with `===` and `!==`: Just result
>>>> in `false` when the types don't match.
>>>>
>>>> -- T.J. Crowder
>>>>
>>>>
>>>> On Thu, Apr 13, 2017 at 12:29 PM, James Treworgy <jamie...@gmail.com>
>>>> wrote:
>>>>
>>>>> I am of the opinion that this isn't really a worthwhile effort in the
>>>>> context of a non-typed language. There are several issues.
>>>>>
>>>>> First, it doesn't actually create any parity with ===. Triple equals
>>>>> never throws an error, it just returns false if the types are unequal.
>>>>> These constructs would change the way the language works fundamentally in
>>>>> that an expression can cause an error which it currently cannot.
>>>>>
>>>>> Second, it really just provides a kind of "too late" poor man's type
>>>>> checking. What you really wanted was a guard when the variable was created
>>>>> or the argumen

Re: Re: Strict Relational Operators

[T.J. Crowder]

Yeah. I suggested that if we aren't doing symbolic operators but rather
functions or something else, they should result in `undefined` for mixed
types, so you can differentiate if appropriate. (Symbolic operators like
`<=<` would need to be consistent with `===` and `!==`, though, which
don't, sadly, do that; and that won't be changing. :-) ) Functions or
non-symbolic operators would have the option of doing that, or throwing,
whatever people end up thinking is best.

-- T.J. Crowder

On Thu, Apr 13, 2017 at 12:41 PM, James Treworgy <jamie...@gmail.com> wrote:

> Put another way  === is useful because you test for strict equality.
> Either it is or is not what you need. But always returning false when
> comparing things with less than or greater than doesn't ensure that you got
> what you want. A false value can be success as much as a true value.
>
> On Apr 13, 2017 7:37 AM, "James Treworgy" <jamie...@gmail.com> wrote:
>
>> Strict expressions. In the case of always returning false, that seems
>> like little help in avoiding bugs to me, since code flow always continues...
>>
>> On Apr 13, 2017 7:35 AM, "T.J. Crowder" <tj.crow...@farsightsoftware.com>
>> wrote:
>>
>>> James, are you commenting on felix's idea of strict expressions (in
>>> which case, I suggest the other thread: https://esdiscuss.org/topic/st
>>> rict-non-coercing-expressions), or strict relational operators?
>>>
>>> Other than felix's strict expressions, I don't think anyone was
>>> suggesting that strict relational operators should throw. It would be
>>> important that they behave consistently with `===` and `!==`: Just result
>>> in `false` when the types don't match.
>>>
>>> -- T.J. Crowder
>>>
>>>
>>> On Thu, Apr 13, 2017 at 12:29 PM, James Treworgy <jamie...@gmail.com>
>>> wrote:
>>>
>>>> I am of the opinion that this isn't really a worthwhile effort in the
>>>> context of a non-typed language. There are several issues.
>>>>
>>>> First, it doesn't actually create any parity with ===. Triple equals
>>>> never throws an error, it just returns false if the types are unequal.
>>>> These constructs would change the way the language works fundamentally in
>>>> that an expression can cause an error which it currently cannot.
>>>>
>>>> Second, it really just provides a kind of "too late" poor man's type
>>>> checking. What you really wanted was a guard when the variable was created
>>>> or the argument passed.  It may provide little help about the actual source
>>>> of the bug.
>>>>
>>>> New syntax and the complexity it creates seems a high price to pay for
>>>> a little band aid.
>>>>
>>>> If we were going to add some simple syntax to try to help this problem
>>>> without going full typescript/flow then I'd be much more in favor of simply
>>>> adding type guard clauses to function arguments that are evaluated at
>>>> runtime.
>>>>
>>>>
>>>> On Apr 13, 2017 2:44 AM, "T.J. Crowder" <tj.crowder@farsightsoftware.c
>>>> om> wrote:
>>>>
>>>>> I've started a separate thread to discuss felix's idea of an
>>>>> expression mode making all operators within it non-coercing (as it's 
>>>>> rather
>>>>> more broad than this topic): https://esdiscuss.org/topic/st
>>>>> rict-non-coercing-expressions
>>>>>
>>>>> -- T.J. Crowder
>>>>>
>>>>>
>>>>> On Thu, Apr 13, 2017 at 6:58 AM, Darien Valentine <
>>>>> valentin...@gmail.com> wrote:
>>>>>
>>>>>> > It's reasonable for non-coercing === to work on different types,
>>>>>> but what would a non-coercing + do with different types? It has to
>>>>>> throw an error.
>>>>>>
>>>>>> Ah, didn’t catch that you were talking about non-relational operators
>>>>>> as well. Assuming a strict `+` was still overloaded for string
>>>>>> concatenation, yeah, an error makes sense (whereas if numeric only, NaN
>>>>>> might also be considered a reasonable answer).
>>>>>>
>>>>>> For strict `<`, etc, I think it would be unintuitive to get an error
>>>>>> or to have arbitrary type order. Rather I’d expect it to be false when 
>>>>>> the
>>>>>> types didn’t match,

Re: Re: Strict Relational Operators

[James Treworgy]

Put another way  === is useful because you test for strict equality. Either
it is or is not what you need. But always returning false when comparing
things with less than or greater than doesn't ensure that you got what you
want. A false value can be success as much as a true value.

On Apr 13, 2017 7:37 AM, "James Treworgy" <jamie...@gmail.com> wrote:

> Strict expressions. In the case of always returning false, that seems like
> little help in avoiding bugs to me, since code flow always continues...
>
> On Apr 13, 2017 7:35 AM, "T.J. Crowder" <tj.crow...@farsightsoftware.com>
> wrote:
>
>> James, are you commenting on felix's idea of strict expressions (in which
>> case, I suggest the other thread: https://esdiscuss.org/topic/st
>> rict-non-coercing-expressions), or strict relational operators?
>>
>> Other than felix's strict expressions, I don't think anyone was
>> suggesting that strict relational operators should throw. It would be
>> important that they behave consistently with `===` and `!==`: Just result
>> in `false` when the types don't match.
>>
>> -- T.J. Crowder
>>
>>
>> On Thu, Apr 13, 2017 at 12:29 PM, James Treworgy <jamie...@gmail.com>
>> wrote:
>>
>>> I am of the opinion that this isn't really a worthwhile effort in the
>>> context of a non-typed language. There are several issues.
>>>
>>> First, it doesn't actually create any parity with ===. Triple equals
>>> never throws an error, it just returns false if the types are unequal.
>>> These constructs would change the way the language works fundamentally in
>>> that an expression can cause an error which it currently cannot.
>>>
>>> Second, it really just provides a kind of "too late" poor man's type
>>> checking. What you really wanted was a guard when the variable was created
>>> or the argument passed.  It may provide little help about the actual source
>>> of the bug.
>>>
>>> New syntax and the complexity it creates seems a high price to pay for a
>>> little band aid.
>>>
>>> If we were going to add some simple syntax to try to help this problem
>>> without going full typescript/flow then I'd be much more in favor of simply
>>> adding type guard clauses to function arguments that are evaluated at
>>> runtime.
>>>
>>>
>>> On Apr 13, 2017 2:44 AM, "T.J. Crowder" <tj.crow...@farsightsoftware.com>
>>> wrote:
>>>
>>>> I've started a separate thread to discuss felix's idea of an expression
>>>> mode making all operators within it non-coercing (as it's rather more broad
>>>> than this topic): https://esdiscuss.org/topic/st
>>>> rict-non-coercing-expressions
>>>>
>>>> -- T.J. Crowder
>>>>
>>>>
>>>> On Thu, Apr 13, 2017 at 6:58 AM, Darien Valentine <
>>>> valentin...@gmail.com> wrote:
>>>>
>>>>> > It's reasonable for non-coercing === to work on different types,
>>>>> but what would a non-coercing + do with different types? It has to
>>>>> throw an error.
>>>>>
>>>>> Ah, didn’t catch that you were talking about non-relational operators
>>>>> as well. Assuming a strict `+` was still overloaded for string
>>>>> concatenation, yeah, an error makes sense (whereas if numeric only, NaN
>>>>> might also be considered a reasonable answer).
>>>>>
>>>>> For strict `<`, etc, I think it would be unintuitive to get an error
>>>>> or to have arbitrary type order. Rather I’d expect it to be false when the
>>>>> types didn’t match, since, for example, the correct answer to both the
>>>>> questions "is seven greater than an object?" and "is an object greater 
>>>>> than
>>>>> 7?" is "no". This would be consistent with the behavior of the existing
>>>>> always-incomparable value, NaN, as well. That said, I think an error would
>>>>> be better than having an arbitrary type order if those were the two 
>>>>> choices.
>>>>>
>>>>> On Thu, Apr 13, 2017 at 12:56 AM, felix <feli...@gmail.com> wrote:
>>>>>
>>>>>> On Wed, Apr 12, 2017 at 7:23 PM, Darien Valentine <
>>>>>> valentin...@gmail.com> wrote:
>>>>>> >> One common JS problem is NaNs ending up in unexpected places, and
>>>>>> it's
>

Re: Re: Strict Relational Operators

[James Treworgy]

Strict expressions. In the case of always returning false, that seems like
little help in avoiding bugs to me, since code flow always continues...

On Apr 13, 2017 7:35 AM, "T.J. Crowder" <tj.crow...@farsightsoftware.com>
wrote:

> James, are you commenting on felix's idea of strict expressions (in which
> case, I suggest the other thread: https://esdiscuss.org/topic/
> strict-non-coercing-expressions), or strict relational operators?
>
> Other than felix's strict expressions, I don't think anyone was suggesting
> that strict relational operators should throw. It would be important that
> they behave consistently with `===` and `!==`: Just result in `false` when
> the types don't match.
>
> -- T.J. Crowder
>
>
> On Thu, Apr 13, 2017 at 12:29 PM, James Treworgy <jamie...@gmail.com>
> wrote:
>
>> I am of the opinion that this isn't really a worthwhile effort in the
>> context of a non-typed language. There are several issues.
>>
>> First, it doesn't actually create any parity with ===. Triple equals
>> never throws an error, it just returns false if the types are unequal.
>> These constructs would change the way the language works fundamentally in
>> that an expression can cause an error which it currently cannot.
>>
>> Second, it really just provides a kind of "too late" poor man's type
>> checking. What you really wanted was a guard when the variable was created
>> or the argument passed.  It may provide little help about the actual source
>> of the bug.
>>
>> New syntax and the complexity it creates seems a high price to pay for a
>> little band aid.
>>
>> If we were going to add some simple syntax to try to help this problem
>> without going full typescript/flow then I'd be much more in favor of simply
>> adding type guard clauses to function arguments that are evaluated at
>> runtime.
>>
>>
>> On Apr 13, 2017 2:44 AM, "T.J. Crowder" <tj.crow...@farsightsoftware.com>
>> wrote:
>>
>>> I've started a separate thread to discuss felix's idea of an expression
>>> mode making all operators within it non-coercing (as it's rather more broad
>>> than this topic): https://esdiscuss.org/topic/st
>>> rict-non-coercing-expressions
>>>
>>> -- T.J. Crowder
>>>
>>>
>>> On Thu, Apr 13, 2017 at 6:58 AM, Darien Valentine <valentin...@gmail.com
>>> > wrote:
>>>
>>>> > It's reasonable for non-coercing === to work on different types, but what
>>>> would a non-coercing + do with different types? It has to throw an
>>>> error.
>>>>
>>>> Ah, didn’t catch that you were talking about non-relational operators
>>>> as well. Assuming a strict `+` was still overloaded for string
>>>> concatenation, yeah, an error makes sense (whereas if numeric only, NaN
>>>> might also be considered a reasonable answer).
>>>>
>>>> For strict `<`, etc, I think it would be unintuitive to get an error or
>>>> to have arbitrary type order. Rather I’d expect it to be false when the
>>>> types didn’t match, since, for example, the correct answer to both the
>>>> questions "is seven greater than an object?" and "is an object greater than
>>>> 7?" is "no". This would be consistent with the behavior of the existing
>>>> always-incomparable value, NaN, as well. That said, I think an error would
>>>> be better than having an arbitrary type order if those were the two 
>>>> choices.
>>>>
>>>> On Thu, Apr 13, 2017 at 12:56 AM, felix <feli...@gmail.com> wrote:
>>>>
>>>>> On Wed, Apr 12, 2017 at 7:23 PM, Darien Valentine <
>>>>> valentin...@gmail.com> wrote:
>>>>> >> One common JS problem is NaNs ending up in unexpected places, and
>>>>> it's
>>>>> >> often difficult to trace back where they came from. Getting a type
>>>>> error
>>>>> >> instead of a NaN would be nice.
>>>>> >
>>>>> > I’m not sure this would help with that. NaN may be the product of
>>>>> coercion,
>>>>> > but NaN itself is a numeric value, and it can be produced without
>>>>> any type
>>>>> > coercion, e.g. `Infinity/Infinity`, `(-1) ** 0.5`, etc. And the `===`
>>>>> > operator is a strict, non-coercive comparison, but that doesn’t mean
>>>>> it
>>>>> > throws type errors.
>>>>>
>

Re: Re: Strict Relational Operators

[T.J. Crowder]

James, are you commenting on felix's idea of strict expressions (in which
case, I suggest the other thread:
https://esdiscuss.org/topic/strict-non-coercing-expressions), or strict
relational operators?

Other than felix's strict expressions, I don't think anyone was suggesting
that strict relational operators should throw. It would be important that
they behave consistently with `===` and `!==`: Just result in `false` when
the types don't match.

-- T.J. Crowder


On Thu, Apr 13, 2017 at 12:29 PM, James Treworgy <jamie...@gmail.com> wrote:

> I am of the opinion that this isn't really a worthwhile effort in the
> context of a non-typed language. There are several issues.
>
> First, it doesn't actually create any parity with ===. Triple equals never
> throws an error, it just returns false if the types are unequal. These
> constructs would change the way the language works fundamentally in that an
> expression can cause an error which it currently cannot.
>
> Second, it really just provides a kind of "too late" poor man's type
> checking. What you really wanted was a guard when the variable was created
> or the argument passed.  It may provide little help about the actual source
> of the bug.
>
> New syntax and the complexity it creates seems a high price to pay for a
> little band aid.
>
> If we were going to add some simple syntax to try to help this problem
> without going full typescript/flow then I'd be much more in favor of simply
> adding type guard clauses to function arguments that are evaluated at
> runtime.
>
>
> On Apr 13, 2017 2:44 AM, "T.J. Crowder" <tj.crow...@farsightsoftware.com>
> wrote:
>
>> I've started a separate thread to discuss felix's idea of an expression
>> mode making all operators within it non-coercing (as it's rather more broad
>> than this topic): https://esdiscuss.org/topic/st
>> rict-non-coercing-expressions
>>
>> -- T.J. Crowder
>>
>>
>> On Thu, Apr 13, 2017 at 6:58 AM, Darien Valentine <valentin...@gmail.com>
>> wrote:
>>
>>> > It's reasonable for non-coercing === to work on different types, but what
>>> would a non-coercing + do with different types? It has to throw an
>>> error.
>>>
>>> Ah, didn’t catch that you were talking about non-relational operators as
>>> well. Assuming a strict `+` was still overloaded for string concatenation,
>>> yeah, an error makes sense (whereas if numeric only, NaN might also be
>>> considered a reasonable answer).
>>>
>>> For strict `<`, etc, I think it would be unintuitive to get an error or
>>> to have arbitrary type order. Rather I’d expect it to be false when the
>>> types didn’t match, since, for example, the correct answer to both the
>>> questions "is seven greater than an object?" and "is an object greater than
>>> 7?" is "no". This would be consistent with the behavior of the existing
>>> always-incomparable value, NaN, as well. That said, I think an error would
>>> be better than having an arbitrary type order if those were the two choices.
>>>
>>> On Thu, Apr 13, 2017 at 12:56 AM, felix <feli...@gmail.com> wrote:
>>>
>>>> On Wed, Apr 12, 2017 at 7:23 PM, Darien Valentine <
>>>> valentin...@gmail.com> wrote:
>>>> >> One common JS problem is NaNs ending up in unexpected places, and
>>>> it's
>>>> >> often difficult to trace back where they came from. Getting a type
>>>> error
>>>> >> instead of a NaN would be nice.
>>>> >
>>>> > I’m not sure this would help with that. NaN may be the product of
>>>> coercion,
>>>> > but NaN itself is a numeric value, and it can be produced without any
>>>> type
>>>> > coercion, e.g. `Infinity/Infinity`, `(-1) ** 0.5`, etc. And the `===`
>>>> > operator is a strict, non-coercive comparison, but that doesn’t mean
>>>> it
>>>> > throws type errors.
>>>>
>>>> Mysterious NaNs in js are usually due to implicit conversion of random
>>>> objects to numbers, not normal numeric computation.
>>>>
>>>> It's reasonable for non-coercing === to work on different types, but
>>>> what would a non-coercing + do with different types? It has to throw
>>>> an error.
>>>>
>>>> Non-coercing < might throw an error or use some arbitrary ordering of
>>>> types. I don't have strong feelings about that.
>>>>
>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Strict Relational Operators

[James Treworgy]

I am of the opinion that this isn't really a worthwhile effort in the
context of a non-typed language. There are several issues.

First, it doesn't actually create any parity with ===. Triple equals never
throws an error, it just returns false if the types are unequal. These
constructs would change the way the language works fundamentally in that an
expression can cause an error which it currently cannot.

Second, it really just provides a kind of "too late" poor man's type
checking. What you really wanted was a guard when the variable was created
or the argument passed.  It may provide little help about the actual source
of the bug.

New syntax and the complexity it creates seems a high price to pay for a
little band aid.

If we were going to add some simple syntax to try to help this problem
without going full typescript/flow then I'd be much more in favor of simply
adding type guard clauses to function arguments that are evaluated at
runtime.


On Apr 13, 2017 2:44 AM, "T.J. Crowder" <tj.crow...@farsightsoftware.com>
wrote:

> I've started a separate thread to discuss felix's idea of an expression
> mode making all operators within it non-coercing (as it's rather more broad
> than this topic): https://esdiscuss.org/topic/strict-non-coercing-
> expressions
>
> -- T.J. Crowder
>
>
> On Thu, Apr 13, 2017 at 6:58 AM, Darien Valentine <valentin...@gmail.com>
> wrote:
>
>> > It's reasonable for non-coercing === to work on different types, but what
>> would a non-coercing + do with different types? It has to throw an error.
>>
>> Ah, didn’t catch that you were talking about non-relational operators as
>> well. Assuming a strict `+` was still overloaded for string concatenation,
>> yeah, an error makes sense (whereas if numeric only, NaN might also be
>> considered a reasonable answer).
>>
>> For strict `<`, etc, I think it would be unintuitive to get an error or
>> to have arbitrary type order. Rather I’d expect it to be false when the
>> types didn’t match, since, for example, the correct answer to both the
>> questions "is seven greater than an object?" and "is an object greater than
>> 7?" is "no". This would be consistent with the behavior of the existing
>> always-incomparable value, NaN, as well. That said, I think an error would
>> be better than having an arbitrary type order if those were the two choices.
>>
>> On Thu, Apr 13, 2017 at 12:56 AM, felix <feli...@gmail.com> wrote:
>>
>>> On Wed, Apr 12, 2017 at 7:23 PM, Darien Valentine <valentin...@gmail.com>
>>> wrote:
>>> >> One common JS problem is NaNs ending up in unexpected places, and it's
>>> >> often difficult to trace back where they came from. Getting a type
>>> error
>>> >> instead of a NaN would be nice.
>>> >
>>> > I’m not sure this would help with that. NaN may be the product of
>>> coercion,
>>> > but NaN itself is a numeric value, and it can be produced without any
>>> type
>>> > coercion, e.g. `Infinity/Infinity`, `(-1) ** 0.5`, etc. And the `===`
>>> > operator is a strict, non-coercive comparison, but that doesn’t mean it
>>> > throws type errors.
>>>
>>> Mysterious NaNs in js are usually due to implicit conversion of random
>>> objects to numbers, not normal numeric computation.
>>>
>>> It's reasonable for non-coercing === to work on different types, but
>>> what would a non-coercing + do with different types? It has to throw
>>> an error.
>>>
>>> Non-coercing < might throw an error or use some arbitrary ordering of
>>> types. I don't have strong feelings about that.
>>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Strict Relational Operators

[T.J. Crowder]

I've started a separate thread to discuss felix's idea of an expression
mode making all operators within it non-coercing (as it's rather more broad
than this topic):
https://esdiscuss.org/topic/strict-non-coercing-expressions

-- T.J. Crowder


On Thu, Apr 13, 2017 at 6:58 AM, Darien Valentine <valentin...@gmail.com>
wrote:

> > It's reasonable for non-coercing === to work on different types, but what
> would a non-coercing + do with different types? It has to throw an error.
>
> Ah, didn’t catch that you were talking about non-relational operators as
> well. Assuming a strict `+` was still overloaded for string concatenation,
> yeah, an error makes sense (whereas if numeric only, NaN might also be
> considered a reasonable answer).
>
> For strict `<`, etc, I think it would be unintuitive to get an error or to
> have arbitrary type order. Rather I’d expect it to be false when the types
> didn’t match, since, for example, the correct answer to both the questions
> "is seven greater than an object?" and "is an object greater than 7?" is
> "no". This would be consistent with the behavior of the existing
> always-incomparable value, NaN, as well. That said, I think an error would
> be better than having an arbitrary type order if those were the two choices.
>
> On Thu, Apr 13, 2017 at 12:56 AM, felix <feli...@gmail.com> wrote:
>
>> On Wed, Apr 12, 2017 at 7:23 PM, Darien Valentine <valentin...@gmail.com>
>> wrote:
>> >> One common JS problem is NaNs ending up in unexpected places, and it's
>> >> often difficult to trace back where they came from. Getting a type
>> error
>> >> instead of a NaN would be nice.
>> >
>> > I’m not sure this would help with that. NaN may be the product of
>> coercion,
>> > but NaN itself is a numeric value, and it can be produced without any
>> type
>> > coercion, e.g. `Infinity/Infinity`, `(-1) ** 0.5`, etc. And the `===`
>> > operator is a strict, non-coercive comparison, but that doesn’t mean it
>> > throws type errors.
>>
>> Mysterious NaNs in js are usually due to implicit conversion of random
>> objects to numbers, not normal numeric computation.
>>
>> It's reasonable for non-coercing === to work on different types, but
>> what would a non-coercing + do with different types? It has to throw
>> an error.
>>
>> Non-coercing < might throw an error or use some arbitrary ordering of
>> types. I don't have strong feelings about that.
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Strict Relational Operators

[Darien Valentine]

> It's reasonable for non-coercing === to work on different types, but what
would a non-coercing + do with different types? It has to throw an error.

Ah, didn’t catch that you were talking about non-relational operators as
well. Assuming a strict `+` was still overloaded for string concatenation,
yeah, an error makes sense (whereas if numeric only, NaN might also be
considered a reasonable answer).

For strict `<`, etc, I think it would be unintuitive to get an error or to
have arbitrary type order. Rather I’d expect it to be false when the types
didn’t match, since, for example, the correct answer to both the questions
"is seven greater than an object?" and "is an object greater than 7?" is
"no". This would be consistent with the behavior of the existing
always-incomparable value, NaN, as well. That said, I think an error would
be better than having an arbitrary type order if those were the two choices.

On Thu, Apr 13, 2017 at 12:56 AM, felix <feli...@gmail.com> wrote:

> On Wed, Apr 12, 2017 at 7:23 PM, Darien Valentine <valentin...@gmail.com>
> wrote:
> >> One common JS problem is NaNs ending up in unexpected places, and it's
> >> often difficult to trace back where they came from. Getting a type error
> >> instead of a NaN would be nice.
> >
> > I’m not sure this would help with that. NaN may be the product of
> coercion,
> > but NaN itself is a numeric value, and it can be produced without any
> type
> > coercion, e.g. `Infinity/Infinity`, `(-1) ** 0.5`, etc. And the `===`
> > operator is a strict, non-coercive comparison, but that doesn’t mean it
> > throws type errors.
>
> Mysterious NaNs in js are usually due to implicit conversion of random
> objects to numbers, not normal numeric computation.
>
> It's reasonable for non-coercing === to work on different types, but
> what would a non-coercing + do with different types? It has to throw
> an error.
>
> Non-coercing < might throw an error or use some arbitrary ordering of
> types. I don't have strong feelings about that.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Strict Relational Operators

[felix]

On Wed, Apr 12, 2017 at 7:23 PM, Darien Valentine  wrote:
>> One common JS problem is NaNs ending up in unexpected places, and it's
>> often difficult to trace back where they came from. Getting a type error
>> instead of a NaN would be nice.
>
> I’m not sure this would help with that. NaN may be the product of coercion,
> but NaN itself is a numeric value, and it can be produced without any type
> coercion, e.g. `Infinity/Infinity`, `(-1) ** 0.5`, etc. And the `===`
> operator is a strict, non-coercive comparison, but that doesn’t mean it
> throws type errors.

Mysterious NaNs in js are usually due to implicit conversion of random
objects to numbers, not normal numeric computation.

It's reasonable for non-coercing === to work on different types, but
what would a non-coercing + do with different types? It has to throw
an error.

Non-coercing < might throw an error or use some arbitrary ordering of
types. I don't have strong feelings about that.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Strict Relational Operators

[Darien Valentine]

> One common JS problem is NaNs ending up in unexpected places, and it's often
difficult to trace back where they came from. Getting a type error instead
of a NaN would be nice.

I’m not sure this would help with that. NaN may be the product of coercion,
but NaN itself is a numeric value, and it can be produced without any type
coercion, e.g. `Infinity/Infinity`, `(-1) ** 0.5`, etc. And the `===`
operator is a strict, non-coercive comparison, but that doesn’t mean it
throws type errors.

On Wed, Apr 12, 2017 at 7:48 PM, felix <feli...@gmail.com> wrote:

> One common JS problem is NaNs ending up in unexpected places, and it's
> often difficult to trace back where they came from. Getting a type
> error instead of a NaN would be nice.
>
> I think this is a reasonable argument for being able to write
> expressions with non-coercing operators, and this is why I'd lean
> toward annotating an entire expression as non-coercing, instead of
> doubling the number of operators.
>
> On Wed, Apr 12, 2017 at 9:25 AM, T.J. Crowder
> <tj.crow...@farsightsoftware.com> wrote:
> > FWIW, I think the next steps for this discussion are:
> >
> > 1. To hear from people whether they feel the need for these operations in
> > their everyday work. It's interesting, you so often hear people saying
> > "Always use `===`, not `==`!" with...fervor...but apparently strict
> versions
> > of the relational operators aren't (or weren't) on people's minds. :-)
> >
> > 2. To hear from implementers about the difficulty level of adding four
> more
> > symbolic operators (`<=<`, `<==`, `>=>`, and `>==` or whatever they end
> up
> > being).
> >
> > (I like my non-symbolic operators -- `lt`, `lte`, and such -- but I doubt
> > they'd pass muster, for the reasons Brendan flagged up in the thread
> about
> > infix functions.)
> >
> > If the answer to #1 is "meh," discussions of operators vs. functions is
> > moot; nothing's going to happen. If the answer to #1 is "Oh yes, this
> would
> > be really useful" and the answer to #2 is "Fairly straightforward",
> that's a
> > solid steer as well, as is a "Actually, surprisingly hard" to #2 (and it
> > would be surprising, at least to me, but what do I know about
> implementing a
> > JavaScript engine).
> >
> > -- T.J. Crowder
> >
> > On Wed, Apr 12, 2017 at 4:49 PM, Michael J. Ryan <track...@gmail.com>
> wrote:
> >>
> >> That's part of why I suggested it... My mention of Object.* Was mainly
> >> that it could defer to a common base class/constructor implementation
> for
> >> comparison.  And that a string and number implementation should be
> >> provided...
> >>
> >> I'm also good with having non-matching types return undefined while
> >> matching types is a Boolean.
> >>
> >> Object.* could just defer to the prototype implementation of the first
> >> value.. null or undefined always returning undefined.
> >>
> >> --
> >> Michael J. Ryan - track...@gmail.com - http://tracker1.info
> >>
> >> Please excuse grammar errors and typos, as this message was sent from my
> >> phone.
> >>
> >> On Apr 12, 2017 7:04 AM, "Darien Valentine" <valentin...@gmail.com>
> wrote:
> >>>
> >>> > Personally I think `a < b` should just become a compile error if the
> >>> > types are not number.
> >>>
> >>> Breaking stuff aside, I think this is an important point. The fact that
> >>> the LT/GT operators do work on strings is a source of bugs. As with
> default
> >>> sort, I’ve seen code written a number of times where it was evident the
> >>> author expected the behavior would be more like
> >>> `Intl.Collator.prototype.compare`.
> >>>
> >>> Unless I’m missing some important common use case for comparing strings
> >>> based on byte values (`assert('a' > 'B')`), I think `Number.gt`,
> >>> `Number.gte`, `Number.lt`, `Number.lte` would be a good solution.
> >>>
> >>> On Wed, Apr 12, 2017 at 5:09 AM, T.J. Crowder
> >>> <tj.crow...@farsightsoftware.com> wrote:
> >>>>
> >>>> > Personally I think `a < b` should just become a compile error if the
> >>>> > types are not number. TypeScript?
> >>>>
> >>>> I'm not following you. JavaScript variables don't have types, so it
> >>>> can't become a compile-time error; and making it one would
> *massivel

Re: Re: Strict Relational Operators

[felix]

One common JS problem is NaNs ending up in unexpected places, and it's
often difficult to trace back where they came from. Getting a type
error instead of a NaN would be nice.

I think this is a reasonable argument for being able to write
expressions with non-coercing operators, and this is why I'd lean
toward annotating an entire expression as non-coercing, instead of
doubling the number of operators.

On Wed, Apr 12, 2017 at 9:25 AM, T.J. Crowder
<tj.crow...@farsightsoftware.com> wrote:
> FWIW, I think the next steps for this discussion are:
>
> 1. To hear from people whether they feel the need for these operations in
> their everyday work. It's interesting, you so often hear people saying
> "Always use `===`, not `==`!" with...fervor...but apparently strict versions
> of the relational operators aren't (or weren't) on people's minds. :-)
>
> 2. To hear from implementers about the difficulty level of adding four more
> symbolic operators (`<=<`, `<==`, `>=>`, and `>==` or whatever they end up
> being).
>
> (I like my non-symbolic operators -- `lt`, `lte`, and such -- but I doubt
> they'd pass muster, for the reasons Brendan flagged up in the thread about
> infix functions.)
>
> If the answer to #1 is "meh," discussions of operators vs. functions is
> moot; nothing's going to happen. If the answer to #1 is "Oh yes, this would
> be really useful" and the answer to #2 is "Fairly straightforward", that's a
> solid steer as well, as is a "Actually, surprisingly hard" to #2 (and it
> would be surprising, at least to me, but what do I know about implementing a
> JavaScript engine).
>
> -- T.J. Crowder
>
> On Wed, Apr 12, 2017 at 4:49 PM, Michael J. Ryan <track...@gmail.com> wrote:
>>
>> That's part of why I suggested it... My mention of Object.* Was mainly
>> that it could defer to a common base class/constructor implementation for
>> comparison.  And that a string and number implementation should be
>> provided...
>>
>> I'm also good with having non-matching types return undefined while
>> matching types is a Boolean.
>>
>> Object.* could just defer to the prototype implementation of the first
>> value.. null or undefined always returning undefined.
>>
>> --
>> Michael J. Ryan - track...@gmail.com - http://tracker1.info
>>
>> Please excuse grammar errors and typos, as this message was sent from my
>> phone.
>>
>> On Apr 12, 2017 7:04 AM, "Darien Valentine" <valentin...@gmail.com> wrote:
>>>
>>> > Personally I think `a < b` should just become a compile error if the
>>> > types are not number.
>>>
>>> Breaking stuff aside, I think this is an important point. The fact that
>>> the LT/GT operators do work on strings is a source of bugs. As with default
>>> sort, I’ve seen code written a number of times where it was evident the
>>> author expected the behavior would be more like
>>> `Intl.Collator.prototype.compare`.
>>>
>>> Unless I’m missing some important common use case for comparing strings
>>> based on byte values (`assert('a' > 'B')`), I think `Number.gt`,
>>> `Number.gte`, `Number.lt`, `Number.lte` would be a good solution.
>>>
>>> On Wed, Apr 12, 2017 at 5:09 AM, T.J. Crowder
>>> <tj.crow...@farsightsoftware.com> wrote:
>>>>
>>>> > Personally I think `a < b` should just become a compile error if the
>>>> > types are not number. TypeScript?
>>>>
>>>> I'm not following you. JavaScript variables don't have types, so it
>>>> can't become a compile-time error; and making it one would *massively* 
>>>> break
>>>> the web. (Yes, you can use TypeScript to get types if you like, but we're
>>>> not talking about TypeScript.)
>>>>
>>>> > ...that's a separable concern which should not be part of the
>>>> > operator's behaviour IMO...
>>>>
>>>> There's no talk of changing how `<` and `>` (or `<=` and `>=`) work.
>>>>
>>>> But just as we have `==` (loose, coercing) and `===` (strict,
>>>> non-coercing), the discussion is about having strict non-coercing versions
>>>> of `<`, `>`, `<=`, and `>=`.
>>>>
>>>> -- T.J. Crowder
>>>>
>>>>
>>>> On Wed, Apr 12, 2017 at 10:00 AM, Alexander Jones <a...@weej.com> wrote:
>>>>>
>>>>> Personally I think `a < b` should just become a compile error if the
>>>>> types are not number. Typ

Re: Re: Strict Relational Operators

[T.J. Crowder]

FWIW, I think the next steps for this discussion are:

1. To hear from people whether they feel the need for these operations in
their everyday work. It's interesting, you so often hear people saying
"Always use `===`, not `==`!" with...fervor...but apparently strict
versions of the relational operators aren't (or weren't) on people's minds.
:-)

2. To hear from implementers about the difficulty level of adding four more
symbolic operators (`<=<`, `<==`, `>=>`, and `>==` or whatever they end up
being).

(I like my non-symbolic operators -- `lt`, `lte`, and such -- but I doubt
they'd pass muster, for the reasons Brendan flagged up in the thread about
infix functions.)

If the answer to #1 is "meh," discussions of operators vs. functions is
moot; nothing's going to happen. If the answer to #1 is "Oh yes, this would
be really useful" and the answer to #2 is "Fairly straightforward", that's
a solid steer as well, as is a "Actually, surprisingly hard" to #2 (and it
would be surprising, at least to me, but what do I know about implementing
a JavaScript engine).

-- T.J. Crowder

On Wed, Apr 12, 2017 at 4:49 PM, Michael J. Ryan <track...@gmail.com> wrote:

> That's part of why I suggested it... My mention of Object.* Was mainly
> that it could defer to a common base class/constructor implementation for
> comparison.  And that a string and number implementation should be
> provided...
>
> I'm also good with having non-matching types return undefined while
> matching types is a Boolean.
>
> Object.* could just defer to the prototype implementation of the first
> value.. null or undefined always returning undefined.
>
> --
> Michael J. Ryan - track...@gmail.com - http://tracker1.info
>
> Please excuse grammar errors and typos, as this message was sent from my
> phone.
>
> On Apr 12, 2017 7:04 AM, "Darien Valentine" <valentin...@gmail.com> wrote:
>
>> > Personally I think `a < b` should just become a compile error if the
>> types are not number.
>>
>> Breaking stuff aside, I think this is an important point. The fact that
>> the LT/GT operators do work on strings is a source of bugs. As with default
>> sort, I’ve seen code written a number of times where it was evident the
>> author expected the behavior would be more like
>> `Intl.Collator.prototype.compare`.
>>
>> Unless I’m missing some important common use case for comparing strings
>> based on byte values (`assert('a' > 'B')`), I think `Number.gt`,
>> `Number.gte`, `Number.lt`, `Number.lte` would be a good solution.
>>
>> On Wed, Apr 12, 2017 at 5:09 AM, T.J. Crowder <
>> tj.crow...@farsightsoftware.com> wrote:
>>
>>> > Personally I think `a < b` should just become a compile error if the
>>> types are not number. TypeScript?
>>>
>>> I'm not following you. JavaScript variables don't have types, so it
>>> can't become a compile-time error; and making it one would *massively*
>>> break the web. (Yes, you can use TypeScript to get types if you like, but
>>> we're not talking about TypeScript.)
>>>
>>> > ...that's a separable concern which should not be part of the
>>> operator's behaviour IMO...
>>>
>>> There's no talk of changing how `<` and `>` (or `<=` and `>=`) work.
>>>
>>> But just as we have `==` (loose, coercing) and `===` (strict,
>>> non-coercing), the discussion is about having strict non-coercing versions
>>> of `<`, `>`, `<=`, and `>=`.
>>>
>>> -- T.J. Crowder
>>>
>>>
>>> On Wed, Apr 12, 2017 at 10:00 AM, Alexander Jones <a...@weej.com> wrote:
>>>
>>>> Personally I think `a < b` should just become a compile error if the
>>>> types are not number. TypeScript?
>>>>
>>>> If you want to also check that they are both number (that's surely what
>>>> we mean here and not that they are both string!) and return `false` if not,
>>>> that's a separable concern which should not be part of the operator's
>>>> behaviour IMO. It would appear to just mask fundamental typing errors,
>>>> unless I am missing some perspective?
>>>>
>>>> Alex
>>>>
>>>> On Wed, 12 Apr 2017 at 09:02, T.J. Crowder <
>>>> tj.crow...@farsightsoftware.com> wrote:
>>>>
>>>>> Grr, there's always something. I forgot to mention that solving this
>>>>> with functions is an option because short-circuiting isn't an issue, both
>>>>> operands have to be evaluated by these relational operators anyw

Re: Re: Strict Relational Operators

[Michael J. Ryan]

That's part of why I suggested it... My mention of Object.* Was mainly that
it could defer to a common base class/constructor implementation for
comparison.  And that a string and number implementation should be
provided...

I'm also good with having non-matching types return undefined while
matching types is a Boolean.

Object.* could just defer to the prototype implementation of the first
value.. null or undefined always returning undefined.

-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Apr 12, 2017 7:04 AM, "Darien Valentine" <valentin...@gmail.com> wrote:

> > Personally I think `a < b` should just become a compile error if the
> types are not number.
>
> Breaking stuff aside, I think this is an important point. The fact that
> the LT/GT operators do work on strings is a source of bugs. As with default
> sort, I’ve seen code written a number of times where it was evident the
> author expected the behavior would be more like `Intl.Collator.prototype.
> compare`.
>
> Unless I’m missing some important common use case for comparing strings
> based on byte values (`assert('a' > 'B')`), I think `Number.gt`,
> `Number.gte`, `Number.lt`, `Number.lte` would be a good solution.
>
> On Wed, Apr 12, 2017 at 5:09 AM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>
>> > Personally I think `a < b` should just become a compile error if the
>> types are not number. TypeScript?
>>
>> I'm not following you. JavaScript variables don't have types, so it can't
>> become a compile-time error; and making it one would *massively* break the
>> web. (Yes, you can use TypeScript to get types if you like, but we're not
>> talking about TypeScript.)
>>
>> > ...that's a separable concern which should not be part of the
>> operator's behaviour IMO...
>>
>> There's no talk of changing how `<` and `>` (or `<=` and `>=`) work.
>>
>> But just as we have `==` (loose, coercing) and `===` (strict,
>> non-coercing), the discussion is about having strict non-coercing versions
>> of `<`, `>`, `<=`, and `>=`.
>>
>> -- T.J. Crowder
>>
>>
>> On Wed, Apr 12, 2017 at 10:00 AM, Alexander Jones <a...@weej.com> wrote:
>>
>>> Personally I think `a < b` should just become a compile error if the
>>> types are not number. TypeScript?
>>>
>>> If you want to also check that they are both number (that's surely what
>>> we mean here and not that they are both string!) and return `false` if not,
>>> that's a separable concern which should not be part of the operator's
>>> behaviour IMO. It would appear to just mask fundamental typing errors,
>>> unless I am missing some perspective?
>>>
>>> Alex
>>>
>>> On Wed, 12 Apr 2017 at 09:02, T.J. Crowder <
>>> tj.crow...@farsightsoftware.com> wrote:
>>>
>>>> Grr, there's always something. I forgot to mention that solving this
>>>> with functions is an option because short-circuiting isn't an issue, both
>>>> operands have to be evaluated by these relational operators anyway. So
>>>> unlike the motiviations for infix functions or macros or whatever, we don't
>>>> have that issue here.
>>>>
>>>> -- T.J. Crowder
>>>>
>>>>
>>>> On Wed, Apr 12, 2017 at 8:56 AM, T.J. Crowder <
>>>> tj.crow...@farsightsoftware.com> wrote:
>>>>
>>>> Very interesting stuff so far.
>>>>
>>>> My take on some options, organized into sections:
>>>>
>>>> * Solving it in userland
>>>> * Using symbolic operators
>>>> * Using functions
>>>> * Using non-symbolic operators
>>>>
>>>> # Solving it in userland:
>>>>
>>>> Anyone wanting strict relational operators today can readily give
>>>> themselves functions for it:
>>>>
>>>> ```js
>>>> const lt = (a, b) => typeof a === typeof b && a < b;
>>>> ```
>>>>
>>>> Usage:
>>>>
>>>> ```js
>>>> if (lt(a, b)) {
>>>> // ...
>>>> }
>>>> ```
>>>>
>>>> So the question is whether the value of having a standard way of
>>>> expressing this is worth the cost of adding it?
>>>>
>>>> Playing into that is that various options come with varying costs:
>>>>
>>>> * Using symbolic operators has a

Re: Re: Strict Relational Operators

[Darien Valentine]

> Personally I think `a < b` should just become a compile error if the
types are not number.

Breaking stuff aside, I think this is an important point. The fact that the
LT/GT operators do work on strings is a source of bugs. As with default
sort, I’ve seen code written a number of times where it was evident the
author expected the behavior would be more like
`Intl.Collator.prototype.compare`.

Unless I’m missing some important common use case for comparing strings
based on byte values (`assert('a' > 'B')`), I think `Number.gt`,
`Number.gte`, `Number.lt`, `Number.lte` would be a good solution.

On Wed, Apr 12, 2017 at 5:09 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> > Personally I think `a < b` should just become a compile error if the
> types are not number. TypeScript?
>
> I'm not following you. JavaScript variables don't have types, so it can't
> become a compile-time error; and making it one would *massively* break the
> web. (Yes, you can use TypeScript to get types if you like, but we're not
> talking about TypeScript.)
>
> > ...that's a separable concern which should not be part of the operator's
> behaviour IMO...
>
> There's no talk of changing how `<` and `>` (or `<=` and `>=`) work.
>
> But just as we have `==` (loose, coercing) and `===` (strict,
> non-coercing), the discussion is about having strict non-coercing versions
> of `<`, `>`, `<=`, and `>=`.
>
> -- T.J. Crowder
>
>
> On Wed, Apr 12, 2017 at 10:00 AM, Alexander Jones <a...@weej.com> wrote:
>
>> Personally I think `a < b` should just become a compile error if the
>> types are not number. TypeScript?
>>
>> If you want to also check that they are both number (that's surely what
>> we mean here and not that they are both string!) and return `false` if not,
>> that's a separable concern which should not be part of the operator's
>> behaviour IMO. It would appear to just mask fundamental typing errors,
>> unless I am missing some perspective?
>>
>> Alex
>>
>> On Wed, 12 Apr 2017 at 09:02, T.J. Crowder <tj.crowder@farsightsoftware.c
>> om> wrote:
>>
>>> Grr, there's always something. I forgot to mention that solving this
>>> with functions is an option because short-circuiting isn't an issue, both
>>> operands have to be evaluated by these relational operators anyway. So
>>> unlike the motiviations for infix functions or macros or whatever, we don't
>>> have that issue here.
>>>
>>> -- T.J. Crowder
>>>
>>>
>>> On Wed, Apr 12, 2017 at 8:56 AM, T.J. Crowder <
>>> tj.crow...@farsightsoftware.com> wrote:
>>>
>>> Very interesting stuff so far.
>>>
>>> My take on some options, organized into sections:
>>>
>>> * Solving it in userland
>>> * Using symbolic operators
>>> * Using functions
>>> * Using non-symbolic operators
>>>
>>> # Solving it in userland:
>>>
>>> Anyone wanting strict relational operators today can readily give
>>> themselves functions for it:
>>>
>>> ```js
>>> const lt = (a, b) => typeof a === typeof b && a < b;
>>> ```
>>>
>>> Usage:
>>>
>>> ```js
>>> if (lt(a, b)) {
>>> // ...
>>> }
>>> ```
>>>
>>> So the question is whether the value of having a standard way of
>>> expressing this is worth the cost of adding it?
>>>
>>> Playing into that is that various options come with varying costs:
>>>
>>> * Using symbolic operators has a cost, but doesn't change fundamentals;
>>> I'm not an implementer, but I'd think the cost would be fairly low (but
>>> non-zero). *Any* syntax change rattles parsing cages everywhere, but syntax
>>> changes are now fairly regular occurrences in JavaScript.
>>> * Using functions means no new syntax, which means not rattling parsing
>>> cages, and are polyfillable.
>>> * Using non-symbolic operators rattles cages, and probably more
>>> significantly than new symbolic ones, and has been rejected in the past
>>> (`is`/`isnt`).
>>>
>>> So that's in the mix.
>>>
>>> # Using symbolic operators:
>>>
>>> ## Form
>>>
>>> The closest I can come to consistency with `==`/`===` and `!=`/`!==` is:
>>>
>>> LooseStrict
>>>  ==   ===
>>>  !=   !==
>>>  <<=<
>>>  >>=>
>>>  <=   <==
>>>  

Re: Re: Strict Relational Operators

[T.J. Crowder]

> Personally I think `a < b` should just become a compile error if the
types are not number. TypeScript?

I'm not following you. JavaScript variables don't have types, so it can't
become a compile-time error; and making it one would *massively* break the
web. (Yes, you can use TypeScript to get types if you like, but we're not
talking about TypeScript.)

> ...that's a separable concern which should not be part of the operator's
behaviour IMO...

There's no talk of changing how `<` and `>` (or `<=` and `>=`) work.

But just as we have `==` (loose, coercing) and `===` (strict,
non-coercing), the discussion is about having strict non-coercing versions
of `<`, `>`, `<=`, and `>=`.

-- T.J. Crowder


On Wed, Apr 12, 2017 at 10:00 AM, Alexander Jones <a...@weej.com> wrote:

> Personally I think `a < b` should just become a compile error if the types
> are not number. TypeScript?
>
> If you want to also check that they are both number (that's surely what we
> mean here and not that they are both string!) and return `false` if not,
> that's a separable concern which should not be part of the operator's
> behaviour IMO. It would appear to just mask fundamental typing errors,
> unless I am missing some perspective?
>
> Alex
>
> On Wed, 12 Apr 2017 at 09:02, T.J. Crowder <tj.crowder@farsightsoftware.
> com> wrote:
>
>> Grr, there's always something. I forgot to mention that solving this with
>> functions is an option because short-circuiting isn't an issue, both
>> operands have to be evaluated by these relational operators anyway. So
>> unlike the motiviations for infix functions or macros or whatever, we don't
>> have that issue here.
>>
>> -- T.J. Crowder
>>
>>
>> On Wed, Apr 12, 2017 at 8:56 AM, T.J. Crowder <
>> tj.crow...@farsightsoftware.com> wrote:
>>
>> Very interesting stuff so far.
>>
>> My take on some options, organized into sections:
>>
>> * Solving it in userland
>> * Using symbolic operators
>> * Using functions
>> * Using non-symbolic operators
>>
>> # Solving it in userland:
>>
>> Anyone wanting strict relational operators today can readily give
>> themselves functions for it:
>>
>> ```js
>> const lt = (a, b) => typeof a === typeof b && a < b;
>> ```
>>
>> Usage:
>>
>> ```js
>> if (lt(a, b)) {
>> // ...
>> }
>> ```
>>
>> So the question is whether the value of having a standard way of
>> expressing this is worth the cost of adding it?
>>
>> Playing into that is that various options come with varying costs:
>>
>> * Using symbolic operators has a cost, but doesn't change fundamentals;
>> I'm not an implementer, but I'd think the cost would be fairly low (but
>> non-zero). *Any* syntax change rattles parsing cages everywhere, but syntax
>> changes are now fairly regular occurrences in JavaScript.
>> * Using functions means no new syntax, which means not rattling parsing
>> cages, and are polyfillable.
>> * Using non-symbolic operators rattles cages, and probably more
>> significantly than new symbolic ones, and has been rejected in the past
>> (`is`/`isnt`).
>>
>> So that's in the mix.
>>
>> # Using symbolic operators:
>>
>> ## Form
>>
>> The closest I can come to consistency with `==`/`===` and `!=`/`!==` is:
>>
>> LooseStrict
>>  ==   ===
>>  !=   !==
>>  <<=<
>>  >>=>
>>  <=   <==
>>  >=   >==
>>
>> We can think of the `=` in the middle as being what signifies the strict
>> type aspect. The second `<` and `>` on `<=<` and `>=>` are a hack, but a
>> reasonable hack that's in the spirit of the original two strict operators.
>> :-)
>>
>> ## Semantics
>>
>> Because they're like `!==` and `===`, their semantics would have to be in
>> line with `!==` and `===`: The result is `true` if the operands are of the
>> same type and the relation is true, `false` otherwise.
>>
>> # Using functions:
>>
>> ## Form
>>
>> Given `Object.is(value1, value2)` there's an argument for putting these
>> on `Object` as well. But `Object` is an odd place for them (and indeed for
>> `is`). Perhaps we need a place for these to go. But sticking with `Object`
>> for now:
>>
>> ```js
>> Object.lt(value1, value2)
>> Object.gt(value1, value2)
>> Object.lte(value1, value2)
>> Object.gte(value1, value2)
>> ```
>>
>> So:
>>
>> `

Re: Re: Strict Relational Operators

[Alexander Jones]

Personally I think `a < b` should just become a compile error if the types
are not number. TypeScript?

If you want to also check that they are both number (that's surely what we
mean here and not that they are both string!) and return `false` if not,
that's a separable concern which should not be part of the operator's
behaviour IMO. It would appear to just mask fundamental typing errors,
unless I am missing some perspective?

Alex

On Wed, 12 Apr 2017 at 09:02, T.J. Crowder <tj.crow...@farsightsoftware.com>
wrote:

> Grr, there's always something. I forgot to mention that solving this with
> functions is an option because short-circuiting isn't an issue, both
> operands have to be evaluated by these relational operators anyway. So
> unlike the motiviations for infix functions or macros or whatever, we don't
> have that issue here.
>
> -- T.J. Crowder
>
>
> On Wed, Apr 12, 2017 at 8:56 AM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>
> Very interesting stuff so far.
>
> My take on some options, organized into sections:
>
> * Solving it in userland
> * Using symbolic operators
> * Using functions
> * Using non-symbolic operators
>
> # Solving it in userland:
>
> Anyone wanting strict relational operators today can readily give
> themselves functions for it:
>
> ```js
> const lt = (a, b) => typeof a === typeof b && a < b;
> ```
>
> Usage:
>
> ```js
> if (lt(a, b)) {
> // ...
> }
> ```
>
> So the question is whether the value of having a standard way of
> expressing this is worth the cost of adding it?
>
> Playing into that is that various options come with varying costs:
>
> * Using symbolic operators has a cost, but doesn't change fundamentals;
> I'm not an implementer, but I'd think the cost would be fairly low (but
> non-zero). *Any* syntax change rattles parsing cages everywhere, but syntax
> changes are now fairly regular occurrences in JavaScript.
> * Using functions means no new syntax, which means not rattling parsing
> cages, and are polyfillable.
> * Using non-symbolic operators rattles cages, and probably more
> significantly than new symbolic ones, and has been rejected in the past
> (`is`/`isnt`).
>
> So that's in the mix.
>
> # Using symbolic operators:
>
> ## Form
>
> The closest I can come to consistency with `==`/`===` and `!=`/`!==` is:
>
> LooseStrict
>  ==   ===
>  !=   !==
>  <<=<
>  >>=>
>  <=   <==
>  >=   >==
>
> We can think of the `=` in the middle as being what signifies the strict
> type aspect. The second `<` and `>` on `<=<` and `>=>` are a hack, but a
> reasonable hack that's in the spirit of the original two strict operators.
> :-)
>
> ## Semantics
>
> Because they're like `!==` and `===`, their semantics would have to be in
> line with `!==` and `===`: The result is `true` if the operands are of the
> same type and the relation is true, `false` otherwise.
>
> # Using functions:
>
> ## Form
>
> Given `Object.is(value1, value2)` there's an argument for putting these on
> `Object` as well. But `Object` is an odd place for them (and indeed for
> `is`). Perhaps we need a place for these to go. But sticking with `Object`
> for now:
>
> ```js
> Object.lt(value1, value2)
> Object.gt(value1, value2)
> Object.lte(value1, value2)
> Object.gte(value1, value2)
> ```
>
> So:
>
> ```js
> if (Object.lt(a, b)) {
> // ...
> }
> ```
>
> Verbose, and again, using `Object` if I'm comparing numbers or strings
> seems wrong. But it's consistent with the prior practice of `Object.is`.
>
> Michael J. Ryan suggested putting them on `Number`, `String`, and `Object`
> instead, on the theory that if you're being strict, you know what you're
> comparing. I'm not sure I agree that you do (a generic "take the lower of
> these two" function, for instance), but there's something there. It doesn't
> address the verbosity issue. (Presumably we only need `Number` and `String`
> though, unless we're going to introduce a whole mechanism for relational
> comparison of objects. Or unless the `Object` version just hands off to the
> `Number` or `String` version based on the first operand type.)
>
> ## Semantics
>
> Using functions gives us the opportunity to use slightly different
> semantics:
>
> 1. `true`: The operands are the same type and the relation is true
> 2. `false`: The operands are the same type and the relation is false
> 3. `undefined`: The operands are of different types
>
> This takes advantage of the fact `undefined` is falsy to not get in the
> wa

Re: Re: Strict Relational Operators

[T.J. Crowder]

Grr, there's always something. I forgot to mention that solving this with
functions is an option because short-circuiting isn't an issue, both
operands have to be evaluated by these relational operators anyway. So
unlike the motiviations for infix functions or macros or whatever, we don't
have that issue here.

-- T.J. Crowder

On Wed, Apr 12, 2017 at 8:56 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> Very interesting stuff so far.
>
> My take on some options, organized into sections:
>
> * Solving it in userland
> * Using symbolic operators
> * Using functions
> * Using non-symbolic operators
>
> # Solving it in userland:
>
> Anyone wanting strict relational operators today can readily give
> themselves functions for it:
>
> ```js
> const lt = (a, b) => typeof a === typeof b && a < b;
> ```
>
> Usage:
>
> ```js
> if (lt(a, b)) {
> // ...
> }
> ```
>
> So the question is whether the value of having a standard way of
> expressing this is worth the cost of adding it?
>
> Playing into that is that various options come with varying costs:
>
> * Using symbolic operators has a cost, but doesn't change fundamentals;
> I'm not an implementer, but I'd think the cost would be fairly low (but
> non-zero). *Any* syntax change rattles parsing cages everywhere, but syntax
> changes are now fairly regular occurrences in JavaScript.
> * Using functions means no new syntax, which means not rattling parsing
> cages, and are polyfillable.
> * Using non-symbolic operators rattles cages, and probably more
> significantly than new symbolic ones, and has been rejected in the past
> (`is`/`isnt`).
>
> So that's in the mix.
>
> # Using symbolic operators:
>
> ## Form
>
> The closest I can come to consistency with `==`/`===` and `!=`/`!==` is:
>
> LooseStrict
>  ==   ===
>  !=   !==
>  <<=<
>  >>=>
>  <=   <==
>  >=   >==
>
> We can think of the `=` in the middle as being what signifies the strict
> type aspect. The second `<` and `>` on `<=<` and `>=>` are a hack, but a
> reasonable hack that's in the spirit of the original two strict operators.
> :-)
>
> ## Semantics
>
> Because they're like `!==` and `===`, their semantics would have to be in
> line with `!==` and `===`: The result is `true` if the operands are of the
> same type and the relation is true, `false` otherwise.
>
> # Using functions:
>
> ## Form
>
> Given `Object.is(value1, value2)` there's an argument for putting these on
> `Object` as well. But `Object` is an odd place for them (and indeed for
> `is`). Perhaps we need a place for these to go. But sticking with `Object`
> for now:
>
> ```js
> Object.lt(value1, value2)
> Object.gt(value1, value2)
> Object.lte(value1, value2)
> Object.gte(value1, value2)
> ```
>
> So:
>
> ```js
> if (Object.lt(a, b)) {
> // ...
> }
> ```
>
> Verbose, and again, using `Object` if I'm comparing numbers or strings
> seems wrong. But it's consistent with the prior practice of `Object.is`.
>
> Michael J. Ryan suggested putting them on `Number`, `String`, and `Object`
> instead, on the theory that if you're being strict, you know what you're
> comparing. I'm not sure I agree that you do (a generic "take the lower of
> these two" function, for instance), but there's something there. It doesn't
> address the verbosity issue. (Presumably we only need `Number` and `String`
> though, unless we're going to introduce a whole mechanism for relational
> comparison of objects. Or unless the `Object` version just hands off to the
> `Number` or `String` version based on the first operand type.)
>
> ## Semantics
>
> Using functions gives us the opportunity to use slightly different
> semantics:
>
> 1. `true`: The operands are the same type and the relation is true
> 2. `false`: The operands are the same type and the relation is false
> 3. `undefined`: The operands are of different types
>
> This takes advantage of the fact `undefined` is falsy to not get in the
> way of people just using the result in a condition, but if they examine the
> result itself, it's possible to differentiate between #2 and #3.
>
> Sadly, `Object.is` (the exposed version of the SameValue algorithm) does
> not make this distinction.
>
> # Non-symbolic operators
>
> JavaScript already has at least one binary operator that isn't symbolic:
> `in`. Maybe there's a case for adding more. Brendan Eich is [on record](
> https://esdiscuss.org/topic/suggestion-mapping-
> symbolic-infix-ops-to-binary-functions#content-5) five years ago as
> h

Re: Re: Strict Relational Operators

[T.J. Crowder]

Very interesting stuff so far.

My take on some options, organized into sections:

* Solving it in userland
* Using symbolic operators
* Using functions
* Using non-symbolic operators

# Solving it in userland:

Anyone wanting strict relational operators today can readily give
themselves functions for it:

```js
const lt = (a, b) => typeof a === typeof b && a < b;
```

Usage:

```js
if (lt(a, b)) {
// ...
}
```

So the question is whether the value of having a standard way of expressing
this is worth the cost of adding it?

Playing into that is that various options come with varying costs:

* Using symbolic operators has a cost, but doesn't change fundamentals; I'm
not an implementer, but I'd think the cost would be fairly low (but
non-zero). *Any* syntax change rattles parsing cages everywhere, but syntax
changes are now fairly regular occurrences in JavaScript.
* Using functions means no new syntax, which means not rattling parsing
cages, and are polyfillable.
* Using non-symbolic operators rattles cages, and probably more
significantly than new symbolic ones, and has been rejected in the past
(`is`/`isnt`).

So that's in the mix.

# Using symbolic operators:

## Form

The closest I can come to consistency with `==`/`===` and `!=`/`!==` is:

LooseStrict
 ==   ===
 !=   !==
 <<=<
 >>=>
 <=   <==
 >=   >==

We can think of the `=` in the middle as being what signifies the strict
type aspect. The second `<` and `>` on `<=<` and `>=>` are a hack, but a
reasonable hack that's in the spirit of the original two strict operators.
:-)

## Semantics

Because they're like `!==` and `===`, their semantics would have to be in
line with `!==` and `===`: The result is `true` if the operands are of the
same type and the relation is true, `false` otherwise.

# Using functions:

## Form

Given `Object.is(value1, value2)` there's an argument for putting these on
`Object` as well. But `Object` is an odd place for them (and indeed for
`is`). Perhaps we need a place for these to go. But sticking with `Object`
for now:

```js
Object.lt(value1, value2)
Object.gt(value1, value2)
Object.lte(value1, value2)
Object.gte(value1, value2)
```

So:

```js
if (Object.lt(a, b)) {
// ...
}
```

Verbose, and again, using `Object` if I'm comparing numbers or strings
seems wrong. But it's consistent with the prior practice of `Object.is`.

Michael J. Ryan suggested putting them on `Number`, `String`, and `Object`
instead, on the theory that if you're being strict, you know what you're
comparing. I'm not sure I agree that you do (a generic "take the lower of
these two" function, for instance), but there's something there. It doesn't
address the verbosity issue. (Presumably we only need `Number` and `String`
though, unless we're going to introduce a whole mechanism for relational
comparison of objects. Or unless the `Object` version just hands off to the
`Number` or `String` version based on the first operand type.)

## Semantics

Using functions gives us the opportunity to use slightly different
semantics:

1. `true`: The operands are the same type and the relation is true
2. `false`: The operands are the same type and the relation is false
3. `undefined`: The operands are of different types

This takes advantage of the fact `undefined` is falsy to not get in the way
of people just using the result in a condition, but if they examine the
result itself, it's possible to differentiate between #2 and #3.

Sadly, `Object.is` (the exposed version of the SameValue algorithm) does
not make this distinction.

# Non-symbolic operators

JavaScript already has at least one binary operator that isn't symbolic:
`in`. Maybe there's a case for adding more. Brendan Eich is [on record](
https://esdiscuss.org/topic/suggestion-mapping-symbolic-infix-ops-to-binary-functions#content-5)
five years ago as having issues with them:

> > modulo, div, divmod, has, extends

> These are much better as methods. Polyfillable, but also not subject to
weird line terminator restrictions on the left. Same arguments killed
is/isnt.

Hence `Object.is`, presumably (the linked discussion was about infix
functions, not `is`). I don't know if that view has shifted in the
subsequent five years; there have been big changes in the way JavaScript
moves forward. But that was an objection at least then.

## Form

`lt`, `lte`, `gt`, and `gte`. And while we're at it, `eq` and `noteq`. So:

```js
if (a lt b) {
// ...
}
```

To avoid breaking the web, the new non-symbolic operators would have to
remain valid identifiers, only being operators by context, a bit like how
`for` can be a literal property name (`obj.for`) as of ES5 because we know
from context that it's not the `for` statement. But I assume (not being a
parser guy) that it's more complex to handle the above (those "weird line
terminator conditions on the left" Eich

Re: Re: Strict Relational Operators

[Michael J. Ryan]

Thinking on it... (Number|Object|String) .strict(Equal|Greater|Less...)
Methods (a, b) might be better...  If either value isn't a match for the
bound type, it's a false, even if both sides are equal...

Ex,.

Number.strictEqual(null, null)  false

Object.strictEqual(1, 1)  false
...

If you're doing a strict compare, one can presume you should know what
you're comparing.


-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Apr 11, 2017 10:46 PM, "felix" <feli...@gmail.com> wrote:

> Maybe every operator can have a non-coercing variant?
>
> One possible syntax is to have a modifier on operators
> x = a (<) b (+) c (&&) (!)d;
> if (x (!=) y) ...
>
> Another possible syntax is to have a modifier on expressions
> x = #(a < b + c && !d)
> if #(x != y) ...
>
> On Tue, Apr 11, 2017 at 7:48 PM, Darien Valentine <valentin...@gmail.com>
> wrote:
> > Although I’m unsure if this is wise given there are already eleven
> symbols
> > that are combinations of `=` and `<`/`>`, for symmetry with `==` and
> `===`
> > I’d imagine something like this:
> >
> > ```
> > COERCIVE  STRICT
> >> =>=
> > < =<=
> >>==>==
> > <==<==
> > ```
> >
> > Could also follow the pattern `>==` (strict GT) and `<===` (strict GTE),
> > which avoids the awkwardness of the latter two sharing opening chars with
> > `=>`, but that seems more ambiguous since `>==` doesn’t let you infer
> > whether it means strict GT or strict GTE.
> >
> > It’d be nice to have this functionality built in, but I wonder if it’d
> > possibly be preferable to provide it through methods of one of the
> built-in
> > objects, rather than as operators. Functions after all are more flexible.
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Strict Relational Operators

[felix]

Maybe every operator can have a non-coercing variant?

One possible syntax is to have a modifier on operators
x = a (<) b (+) c (&&) (!)d;
if (x (!=) y) ...

Another possible syntax is to have a modifier on expressions
x = #(a < b + c && !d)
if #(x != y) ...

On Tue, Apr 11, 2017 at 7:48 PM, Darien Valentine <valentin...@gmail.com> wrote:
> Although I’m unsure if this is wise given there are already eleven symbols
> that are combinations of `=` and `<`/`>`, for symmetry with `==` and `===`
> I’d imagine something like this:
>
> ```
> COERCIVE  STRICT
>> =>=
> < =<=
>>==>==
> <==<==
> ```
>
> Could also follow the pattern `>==` (strict GT) and `<===` (strict GTE),
> which avoids the awkwardness of the latter two sharing opening chars with
> `=>`, but that seems more ambiguous since `>==` doesn’t let you infer
> whether it means strict GT or strict GTE.
>
> It’d be nice to have this functionality built in, but I wonder if it’d
> possibly be preferable to provide it through methods of one of the built-in
> objects, rather than as operators. Functions after all are more flexible.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Strict Relational Operators

[Darien Valentine]

Although I’m unsure if this is wise given there are already eleven symbols
that are combinations of `=` and `<`/`>`, for symmetry with `==` and `===`
I’d imagine something like this:

```
COERCIVE  STRICT
> =>=
< =<=
>==>==
<==<==
```

Could also follow the pattern `>==` (strict GT) and `<===` (strict GTE),
which avoids the awkwardness of the latter two sharing opening chars with
`=>`, but that seems more ambiguous since `>==` doesn’t let you infer
whether it means strict GT or strict GTE.

It’d be nice to have this functionality built in, but I wonder if it’d
possibly be preferable to provide it through methods of one of the built-in
objects, rather than as operators. Functions after all are more flexible.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Strict Relational Operators

[Michael J. Ryan]

It's definitely an interesting idea...  Been trying to consider what
character would be added to represent a strict comparison...  Perhaps @?

>@  <@  <=@ >=@ ...

Not sure how this might conflict with decorators...

-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Apr 10, 2017 9:48 AM, "Isiah Meadows" <isiahmead...@gmail.com> wrote:

> I'm not sure there has been prior discussion. A lot of stuff has
> already been discussed in depth, but that I don't think is one of
> them.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
>
> On Mon, Apr 10, 2017 at 3:47 AM, T.J. Crowder
> <tj.crow...@farsightsoftware.com> wrote:
> > I'm sure there must have been discussions of adding strict relational
> > operators (e.g., non-coercing ones, the `===` versions of `<`, `>`, `<=`,
> > and `>=`), but I'm not having a lot of luck finding those discussions.
> > Searching "strict relational
> > site:https://mail.mozilla.org/pipermail/es-discuss/; and on
> esdiscuss.org
> > doesn't turn up anything relevant.
> >
> > Does anyone have a link handy? I'm not trying to start a new discussion,
> > just keen to read what's already been discussed.
> >
> > Thanks,
> >
> > -- T.J. Crowder
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Strict Relational Operators

[Isiah Meadows]

I'm not sure there has been prior discussion. A lot of stuff has
already been discussed in depth, but that I don't think is one of
them.
-

Isiah Meadows
m...@isiahmeadows.com


On Mon, Apr 10, 2017 at 3:47 AM, T.J. Crowder
<tj.crow...@farsightsoftware.com> wrote:
> I'm sure there must have been discussions of adding strict relational
> operators (e.g., non-coercing ones, the `===` versions of `<`, `>`, `<=`,
> and `>=`), but I'm not having a lot of luck finding those discussions.
> Searching "strict relational
> site:https://mail.mozilla.org/pipermail/es-discuss/; and on esdiscuss.org
> doesn't turn up anything relevant.
>
> Does anyone have a link handy? I'm not trying to start a new discussion,
> just keen to read what's already been discussed.
>
> Thanks,
>
> -- T.J. Crowder
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Strict Relational Operators

[Mark S. Miller]

Hi T.J.,

I do not recall such a discussion. Please do start one! Thanks.


On Mon, Apr 10, 2017 at 2:47 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> I'm sure there must have been discussions of adding strict relational
> operators (e.g., non-coercing ones, the `===` versions of `<`, `>`, `<=`,
> and `>=`), but I'm not having a lot of luck finding those discussions.
> Searching "strict relational site:https://mail.mozilla.org/
> pipermail/es-discuss/" and on esdiscuss.org doesn't turn up anything
> relevant.
>
> Does anyone have a link handy? I'm not trying to start a new discussion,
> just keen to read what's already been discussed.
>
> Thanks,
>
> -- T.J. Crowder
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Strict Relational Operators

[T.J. Crowder]

I'm sure there must have been discussions of adding strict relational
operators (e.g., non-coercing ones, the `===` versions of `<`, `>`, `<=`,
and `>=`), but I'm not having a lot of luck finding those discussions.
Searching "strict relational site:
https://mail.mozilla.org/pipermail/es-discuss/; and on esdiscuss.org
doesn't turn up anything relevant.

Does anyone have a link handy? I'm not trying to start a new discussion,
just keen to read what's already been discussed.

Thanks,

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: New Assignment Operators (Not bit-wise OR)

[Brandon Andrews]

Perhaps this proposal might fit with what you had in mind:


https://esdiscuss.org/topic/proposal-for-a-null-coalescing-operator

Been meaning to clean this up and submit it as an actual proposal since the 
idea is kind of simple:

https://github.com/sirisian/ecmascript-null-coalescing-operator
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Assignment Operators (Not bit-wise OR)

[even stensberg]

It's not a situation, but rather in my eyes a cleaner way of declaration.
Have you read the article? Also, having this, makes it more explicit, as it
should pass down values in a one way flow. Here's a gist with an example:
https://goo.gl/1qyjNl . This distracts us a bit from the scenario though,
as I was trying to tell @brendaneich ( and was wrong about) over Twitter.

The main idea is to make the copy of the variable prefixed with a standard
name, so `var item = item || 'hello'` would have the RHS to be more
intuitive and isolated from the actual variable name. As explained in the
article , it might seem like a big load of nonsense, but I think It would
be well worth the cause.



On Tue, Apr 19, 2016 at 3:22 AM, Michael Theriot <
michael.lee.ther...@gmail.com> wrote:

> What scenarios do you need to declare a new variable equal to its current
> declaration or a default value?
>
> On Sun, Apr 17, 2016 at 8:21 AM, even stensberg <evenstensb...@gmail.com>
> wrote:
>
>> I've seen a lot of code using an extra type to have as a fallback. This
>> to me seems like not a very good way of putting use of the logical OR.
>> Here's an example:
>>
>> `var itemList = itemList || 'something went extremely wrong'`
>>
>>
>> This is a really hacky way of doing things. I don't think you should
>> assign your variable to a default by doing this.
>>
>>
>> Been back and forth by this "issue" with some of the ReactJS members at
>> GitHub, and while saying this is a "stylus" thing, I disagree. It is more
>> about not reiterating your code.
>>
>> Options could be:
>>
>> -tenaries - long & !clean codelines
>> -default params (ES) , though it won't be a general use case
>>
>> There is already a lot of assignment, string and so on operators, but I
>> don't really seem any of them touch this, except maybe the bit-wise OR
>> assignment Operator. To read more about that, check these two links out:
>>
>> https://msdn.microsoft.com/en-us/library/81bads72(v=vs.94).aspx
>> http://web.eecs.umich.edu/~bartlett/jsops.html
>> http://stackoverflow.com/a/14871137/5893008
>>
>> And that is really not the use case here. We don't want a bit-wise, we
>> want a logical OR.
>>
>> So here is what I come up with. It's not rocket science but ... nah, it's
>> pretty straight forward..
>>
>> `var listItem || = 'I love open source!'`
>>
>>
>> For me, this is one thousand times more clean and it makes sense.
>> JavaScript teaches us and wants us to use `+ =`,` - =` and any other
>> type of "abbreviation" , so this makes perfectly sense for me. Either I'm
>> crazy, but it seems like this should have been implemented a long time ago.
>> ( Perhaps I'm both).
>>
>> Implementation will be another issue, but let us discuss that too( just
>> keep in mind this is conceptional)
>>
>>
>> Without further ado, I leave this up to you to discuss, and hopefully a
>> champion to fetch up to the committee.
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Assignment Operators (Not bit-wise OR)

[Michael Theriot]

What scenarios do you need to declare a new variable equal to its current
declaration or a default value?

On Sun, Apr 17, 2016 at 8:21 AM, even stensberg <evenstensb...@gmail.com>
wrote:

> I've seen a lot of code using an extra type to have as a fallback. This to
> me seems like not a very good way of putting use of the logical OR. Here's
> an example:
>
> `var itemList = itemList || 'something went extremely wrong'`
>
>
> This is a really hacky way of doing things. I don't think you should
> assign your variable to a default by doing this.
>
>
> Been back and forth by this "issue" with some of the ReactJS members at
> GitHub, and while saying this is a "stylus" thing, I disagree. It is more
> about not reiterating your code.
>
> Options could be:
>
> -tenaries - long & !clean codelines
> -default params (ES) , though it won't be a general use case
>
> There is already a lot of assignment, string and so on operators, but I
> don't really seem any of them touch this, except maybe the bit-wise OR
> assignment Operator. To read more about that, check these two links out:
>
> https://msdn.microsoft.com/en-us/library/81bads72(v=vs.94).aspx
> http://web.eecs.umich.edu/~bartlett/jsops.html
> http://stackoverflow.com/a/14871137/5893008
>
> And that is really not the use case here. We don't want a bit-wise, we
> want a logical OR.
>
> So here is what I come up with. It's not rocket science but ... nah, it's
> pretty straight forward..
>
> `var listItem || = 'I love open source!'`
>
>
> For me, this is one thousand times more clean and it makes sense.
> JavaScript teaches us and wants us to use `+ =`,` - =` and any other type
> of "abbreviation" , so this makes perfectly sense for me. Either I'm crazy,
> but it seems like this should have been implemented a long time ago.
> ( Perhaps I'm both).
>
> Implementation will be another issue, but let us discuss that too( just
> keep in mind this is conceptional)
>
>
> Without further ado, I leave this up to you to discuss, and hopefully a
> champion to fetch up to the committee.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Assignment Operators (Not bit-wise OR)

[even stensberg]

I wrote up this medium article describing a new way
https://medium.com/@ev1stensberg/iteration-in-javascript-needs-a-tectonic-shift-a74b6554bbd7#.6cff5a1r7
,
 good enough to submit a proposal?
It will need some fixes in syntax, but I think this could be a nice /
decent fix.

On Sun, Apr 17, 2016 at 9:42 PM, even stensberg <evenstensb...@gmail.com>
wrote:

> Could we use XOR? We would set the variable to false by default, meaning
> if it doesn't contain any values, it will return the OR property. By
> example:
>
> true is a string and boolean in the first example and boolean in the other
> one.
>
> `var false = false || 'true'` This means: false XOR false XOR true = true
> if it is set, we use true XOR true XOR false = false , which will return
> the value of our variable.
>
> Example by function: ` function() {
>  var false = true
>  evalToTrue()
>  // outputs 'true'
>  }`
>
> `function() {
> var false = false
> evalToTrue()
> // outputs the value of false
> }
>
> `evalToTrue()` here means the XOR calculation.
>
> On Sun, Apr 17, 2016 at 6:30 PM, Jordan Harband <ljh...@gmail.com> wrote:
>
>> This has been discussed many times before:
>>  - https://esdiscuss.org/topic/operators-and
>>  - https://esdiscuss.org/topic/logical-assignment-operators
>>  - https://esdiscuss.org/topic/is-much-needed
>>  - https://esdiscuss.org/topic/please-add-orequal-operator
>>
>> If you read through these threads, you may find that it's not as
>> straightforward as you think. Would it use truthiness? "not null or
>> undefined"? Just "not undefined"? If it behaves differently than `II`, what
>> about all the confusion that would cause, since it would be the first "LHS
>> x-equals RHS" that didn't behave the same as "LHS equals LHS x RHS"?
>>
>> A proposal would, at the least, need to have addressed all these concerns
>> as well as made it clear that it had located and addressed all prior
>> concerns on the subject, such as the ones linked above.
>>
>> On Sun, Apr 17, 2016 at 6:21 AM, even stensberg <evenstensb...@gmail.com>
>> wrote:
>>
>>> I've seen a lot of code using an extra type to have as a fallback. This
>>> to me seems like not a very good way of putting use of the logical OR.
>>> Here's an example:
>>>
>>> `var itemList = itemList || 'something went extremely wrong'`
>>>
>>>
>>> This is a really hacky way of doing things. I don't think you should
>>> assign your variable to a default by doing this.
>>>
>>>
>>> Been back and forth by this "issue" with some of the ReactJS members at
>>> GitHub, and while saying this is a "stylus" thing, I disagree. It is more
>>> about not reiterating your code.
>>>
>>> Options could be:
>>>
>>> -tenaries - long & !clean codelines
>>> -default params (ES) , though it won't be a general use case
>>>
>>> There is already a lot of assignment, string and so on operators, but I
>>> don't really seem any of them touch this, except maybe the bit-wise OR
>>> assignment Operator. To read more about that, check these two links out:
>>>
>>> https://msdn.microsoft.com/en-us/library/81bads72(v=vs.94).aspx
>>> http://web.eecs.umich.edu/~bartlett/jsops.html
>>> http://stackoverflow.com/a/14871137/5893008
>>>
>>> And that is really not the use case here. We don't want a bit-wise, we
>>> want a logical OR.
>>>
>>> So here is what I come up with. It's not rocket science but ... nah,
>>> it's pretty straight forward..
>>>
>>> `var listItem || = 'I love open source!'`
>>>
>>>
>>> For me, this is one thousand times more clean and it makes sense.
>>> JavaScript teaches us and wants us to use `+ =`,` - =` and any other
>>> type of "abbreviation" , so this makes perfectly sense for me. Either I'm
>>> crazy, but it seems like this should have been implemented a long time ago.
>>> ( Perhaps I'm both).
>>>
>>> Implementation will be another issue, but let us discuss that too( just
>>> keep in mind this is conceptional)
>>>
>>>
>>> Without further ado, I leave this up to you to discuss, and hopefully a
>>> champion to fetch up to the committee.
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Assignment Operators (Not bit-wise OR)

[even stensberg]

Could we use XOR? We would set the variable to false by default, meaning if
it doesn't contain any values, it will return the OR property. By example:

true is a string and boolean in the first example and boolean in the other
one.

`var false = false || 'true'` This means: false XOR false XOR true = true
if it is set, we use true XOR true XOR false = false , which will return
the value of our variable.

Example by function: ` function() {
 var false = true
 evalToTrue()
 // outputs 'true'
 }`

`function() {
var false = false
evalToTrue()
// outputs the value of false
}

`evalToTrue()` here means the XOR calculation.

On Sun, Apr 17, 2016 at 6:30 PM, Jordan Harband <ljh...@gmail.com> wrote:

> This has been discussed many times before:
>  - https://esdiscuss.org/topic/operators-and
>  - https://esdiscuss.org/topic/logical-assignment-operators
>  - https://esdiscuss.org/topic/is-much-needed
>  - https://esdiscuss.org/topic/please-add-orequal-operator
>
> If you read through these threads, you may find that it's not as
> straightforward as you think. Would it use truthiness? "not null or
> undefined"? Just "not undefined"? If it behaves differently than `II`, what
> about all the confusion that would cause, since it would be the first "LHS
> x-equals RHS" that didn't behave the same as "LHS equals LHS x RHS"?
>
> A proposal would, at the least, need to have addressed all these concerns
> as well as made it clear that it had located and addressed all prior
> concerns on the subject, such as the ones linked above.
>
> On Sun, Apr 17, 2016 at 6:21 AM, even stensberg <evenstensb...@gmail.com>
> wrote:
>
>> I've seen a lot of code using an extra type to have as a fallback. This
>> to me seems like not a very good way of putting use of the logical OR.
>> Here's an example:
>>
>> `var itemList = itemList || 'something went extremely wrong'`
>>
>>
>> This is a really hacky way of doing things. I don't think you should
>> assign your variable to a default by doing this.
>>
>>
>> Been back and forth by this "issue" with some of the ReactJS members at
>> GitHub, and while saying this is a "stylus" thing, I disagree. It is more
>> about not reiterating your code.
>>
>> Options could be:
>>
>> -tenaries - long & !clean codelines
>> -default params (ES) , though it won't be a general use case
>>
>> There is already a lot of assignment, string and so on operators, but I
>> don't really seem any of them touch this, except maybe the bit-wise OR
>> assignment Operator. To read more about that, check these two links out:
>>
>> https://msdn.microsoft.com/en-us/library/81bads72(v=vs.94).aspx
>> http://web.eecs.umich.edu/~bartlett/jsops.html
>> http://stackoverflow.com/a/14871137/5893008
>>
>> And that is really not the use case here. We don't want a bit-wise, we
>> want a logical OR.
>>
>> So here is what I come up with. It's not rocket science but ... nah, it's
>> pretty straight forward..
>>
>> `var listItem || = 'I love open source!'`
>>
>>
>> For me, this is one thousand times more clean and it makes sense.
>> JavaScript teaches us and wants us to use `+ =`,` - =` and any other
>> type of "abbreviation" , so this makes perfectly sense for me. Either I'm
>> crazy, but it seems like this should have been implemented a long time ago.
>> ( Perhaps I'm both).
>>
>> Implementation will be another issue, but let us discuss that too( just
>> keep in mind this is conceptional)
>>
>>
>> Without further ado, I leave this up to you to discuss, and hopefully a
>> champion to fetch up to the committee.
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Assignment Operators (Not bit-wise OR)

[Jordan Harband]

This has been discussed many times before:
 - https://esdiscuss.org/topic/operators-and
 - https://esdiscuss.org/topic/logical-assignment-operators
 - https://esdiscuss.org/topic/is-much-needed
 - https://esdiscuss.org/topic/please-add-orequal-operator

If you read through these threads, you may find that it's not as
straightforward as you think. Would it use truthiness? "not null or
undefined"? Just "not undefined"? If it behaves differently than `II`, what
about all the confusion that would cause, since it would be the first "LHS
x-equals RHS" that didn't behave the same as "LHS equals LHS x RHS"?

A proposal would, at the least, need to have addressed all these concerns
as well as made it clear that it had located and addressed all prior
concerns on the subject, such as the ones linked above.

On Sun, Apr 17, 2016 at 6:21 AM, even stensberg <evenstensb...@gmail.com>
wrote:

> I've seen a lot of code using an extra type to have as a fallback. This to
> me seems like not a very good way of putting use of the logical OR. Here's
> an example:
>
> `var itemList = itemList || 'something went extremely wrong'`
>
>
> This is a really hacky way of doing things. I don't think you should
> assign your variable to a default by doing this.
>
>
> Been back and forth by this "issue" with some of the ReactJS members at
> GitHub, and while saying this is a "stylus" thing, I disagree. It is more
> about not reiterating your code.
>
> Options could be:
>
> -tenaries - long & !clean codelines
> -default params (ES) , though it won't be a general use case
>
> There is already a lot of assignment, string and so on operators, but I
> don't really seem any of them touch this, except maybe the bit-wise OR
> assignment Operator. To read more about that, check these two links out:
>
> https://msdn.microsoft.com/en-us/library/81bads72(v=vs.94).aspx
> http://web.eecs.umich.edu/~bartlett/jsops.html
> http://stackoverflow.com/a/14871137/5893008
>
> And that is really not the use case here. We don't want a bit-wise, we
> want a logical OR.
>
> So here is what I come up with. It's not rocket science but ... nah, it's
> pretty straight forward..
>
> `var listItem || = 'I love open source!'`
>
>
> For me, this is one thousand times more clean and it makes sense.
> JavaScript teaches us and wants us to use `+ =`,` - =` and any other type
> of "abbreviation" , so this makes perfectly sense for me. Either I'm crazy,
> but it seems like this should have been implemented a long time ago.
> ( Perhaps I'm both).
>
> Implementation will be another issue, but let us discuss that too( just
> keep in mind this is conceptional)
>
>
> Without further ado, I leave this up to you to discuss, and hopefully a
> champion to fetch up to the committee.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

New Assignment Operators (Not bit-wise OR)

[even stensberg]

I've seen a lot of code using an extra type to have as a fallback. This to
me seems like not a very good way of putting use of the logical OR. Here's
an example:

`var itemList = itemList || 'something went extremely wrong'`


This is a really hacky way of doing things. I don't think you should assign
your variable to a default by doing this.


Been back and forth by this "issue" with some of the ReactJS members at
GitHub, and while saying this is a "stylus" thing, I disagree. It is more
about not reiterating your code.

Options could be:

-tenaries - long & !clean codelines
-default params (ES) , though it won't be a general use case

There is already a lot of assignment, string and so on operators, but I
don't really seem any of them touch this, except maybe the bit-wise OR
assignment Operator. To read more about that, check these two links out:

https://msdn.microsoft.com/en-us/library/81bads72(v=vs.94).aspx
http://web.eecs.umich.edu/~bartlett/jsops.html
http://stackoverflow.com/a/14871137/5893008

And that is really not the use case here. We don't want a bit-wise, we want
a logical OR.

So here is what I come up with. It's not rocket science but ... nah, it's
pretty straight forward..

`var listItem || = 'I love open source!'`


For me, this is one thousand times more clean and it makes sense.
JavaScript teaches us and wants us to use `+ =`,` - =` and any other type
of "abbreviation" , so this makes perfectly sense for me. Either I'm crazy,
but it seems like this should have been implemented a long time ago.
( Perhaps I'm both).

Implementation will be another issue, but let us discuss that too( just
keep in mind this is conceptional)


Without further ado, I leave this up to you to discuss, and hopefully a
champion to fetch up to the committee.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extending spread operators to work with numbers

[Isiah Meadows]

If this says anything, both CoffeeScript and LiveScript implement this
operator. I'm neutral on the proposal, though.

On Sun, Jan 24, 2016, 16:15 kdex <k...@kdex.de> wrote:

> Just a quick idea: The range operator could also be used for non-numeric
> ranges:
>
> ```js
> let latin = ["a" ... "z"];
> // ["a", "b", "c", ..., "x", "y", "z"]
> let latinBackwards = ["z" ... "a"];
> // ["z", "y", "x", ..., "c", "b", "a"]
> let emoji = ["\u{1F601}" ... "\u{1F64F}"]
> // ["\u{1F601}", "\u{1F602}", …, "\u{1F64E}", "\u{1F64F}"]
> ```
>
> On Sonntag, 24. Januar 2016 23:25:35 CET John Gardner wrote:
> > The range operator wouldn't attempt to fill every duty that a Python-like
> > `range` function would. I'd envision it being kept intentionally simple
> (no
> > custom steps, for example). It looks like what it does, and there's no
> > reason the two couldn't co-exist.
> >
> > *can't make mistake (consider [a...b] vs. [a,...b] - is it easy to see
> >
> > > difference?)*
> >
> > That's a non-argument pertaining to an author's formatting choice.
> >
> > On 24 January 2016 at 23:13, Michał Wadas <michalwa...@gmail.com> wrote:
> > > I want to ask why new syntax would be better than Python-like `range`
> > > function?
> > >
> > > Cons of range:
> > > - normal function rather than new syntax
> > > - can be used as memory efficient generator
> > > - custom step can be defined
> > > - easy to polyfill
> > > - can't make mistake (consider [a...b] vs. [a,...b] - is it easy to see
> > > difference?)
> > >
> > > Disadvantages:
> > > - longer than custom syntax
> > >
> > > On 24 Jan 2016 7:11 am, "John Gardner" <gardnerjo...@gmail.com> wrote:
> > >> *This has all the benefits you seek, including visual clarity, without
> > >>
> > >>> overloading the meaning of an existing token.*
> > >>
> > >> Actually, I beg to differ. Recall that this is valid syntax:
> > >>
> > >> 1.. toString(16);
> > >>
> > >> Furthermore, maintaining a 3-dot notation stays consistent with the
> rest
> > >> and spread operators, both of which already overload each other. For
> sake
> > >> of clarity for this discussion, I'll call this one the "range
> operator".
> > >>
> > >>
> > >> *I think this is one of those issues where the benefit of any new
> syntax
> > >>
> > >>> here does not pay for its complexity costs.*
> > >>
> > >> I don't foresee this raising any complexity issues. The syntax is
> > >> intended chiefly as a way to specify multiple integer ranges where
> > >> indexed
> > >> access is relevant. There wouldn't be any need to specify exclusive or
> > >> inclusive expansion, because it'd always work inclusively. Which is
> what
> > >> I
> > >> believe every author would expect when they write 1 ... 5.
> > >>
> > >> It would also enable one to write this:
> > >>
> > >> func( 0 ... 5 )
> > >>
> > >> Instead of this:
> > >>
> > >> func( ...[0, 1, 2, 3, 4, 5] );
> > >>
> > >>
> > >> I can't speak on anybody else's behalf, but I know which of the two
> I'd
> > >> prefer writing.
> > >>
> > >> Again, I'll state I don't expect this to be a groundbreaking feature.
> But
> > >> it's simple, clean and (from what I understand) would be unintrusive
> to
> > >> the
> > >> language.
> > >>
> > >> On 24 January 2016 at 05:41, Mark S. Miller <erig...@google.com>
> wrote:
> > >>> The double dot ("..") is the traditional infix operator for
> > >>> inclusive,inclusive integer ranges, going back to Pascal (the
> language,
> > >>> not
> > >>> the mathematician). This has all the benefits you seek, including
> visual
> > >>> clarity, without overloading the meaning of an existing token.
> > >>>
> > >>> Whether double or triple dot, the problem is that programming
> patterns
> > >>> in zero-index-origin languages want inclusive,exclusive ranges, which
> > >>

Re: Extending spread operators to work with numbers

[Michał Wadas]

I want to ask why new syntax would be better than Python-like `range`
function?

Cons of range:
- normal function rather than new syntax
- can be used as memory efficient generator
- custom step can be defined
- easy to polyfill
- can't make mistake (consider [a...b] vs. [a,...b] - is it easy to see
difference?)

Disadvantages:
- longer than custom syntax
On 24 Jan 2016 7:11 am, "John Gardner" <gardnerjo...@gmail.com> wrote:

> *This has all the benefits you seek, including visual clarity, without
>> overloading the meaning of an existing token.*
>
>
> Actually, I beg to differ. Recall that this is valid syntax:
>
> 1.. toString(16);
>
> Furthermore, maintaining a 3-dot notation stays consistent with the rest
> and spread operators, both of which already overload each other. For sake
> of clarity for this discussion, I'll call this one the "range operator".
>
>
> *I think this is one of those issues where the benefit of any new syntax
>> here does not pay for its complexity costs.*
>
>
> I don't foresee this raising any complexity issues. The syntax is intended
> chiefly as a way to specify multiple integer ranges where indexed access is
> relevant. There wouldn't be any need to specify exclusive or inclusive
> expansion, because it'd always work inclusively. Which is what I believe
> every author would expect when they write 1 ... 5.
>
> It would also enable one to write this:
>
> func( 0 ... 5 )
>
> Instead of this:
>
> func( ...[0, 1, 2, 3, 4, 5] );
>
>
> I can't speak on anybody else's behalf, but I know which of the two I'd
> prefer writing.
>
> Again, I'll state I don't expect this to be a groundbreaking feature. But
> it's simple, clean and (from what I understand) would be unintrusive to the
> language.
>
> On 24 January 2016 at 05:41, Mark S. Miller <erig...@google.com> wrote:
>
>> The double dot ("..") is the traditional infix operator for
>> inclusive,inclusive integer ranges, going back to Pascal (the language, not
>> the mathematician). This has all the benefits you seek, including visual
>> clarity, without overloading the meaning of an existing token.
>>
>> Whether double or triple dot, the problem is that programming patterns in
>> zero-index-origin languages want inclusive,exclusive ranges, which
>> naturally wants an asymmetric syntax to suggest the distinction. The
>> traditional math notation [0, 4) would be unambiguous, since of course we
>> never otherwise allow a closing paren to match an opening square bracket.
>> But, in a programming language context I find it too jarring.
>>
>> E has ".." for inclusive,inclusive ranges, just like Pascal. E also has
>> "..!" for inclusive,exclusive ranges. The second operator was used much
>> more than the first. I don't think "..!" is great but I don't have anything
>> better to suggest.
>>
>> Finally, we must ask whether this problem is worth solving with any
>> syntax or at all. We can already express these well enough with APIs. I
>> think this is one of those issues where the benefit of any new syntax here
>> does not pay for its complexity costs. See *The Tragedy of the Common
>> Lisp, or, Why Large Languages Explode* <
>> https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks
>> >.
>>
>> See also <https://en.wikipedia.org/wiki/Primum_non_nocere>.
>>
>>
>>
>>
>>
>>
>> On Fri, Jan 22, 2016 at 10:20 PM, John Gardner <gardnerjo...@gmail.com>
>> wrote:
>>
>>> Probably a stupid idea, and I can see it already being brought up
>>> several times... but why not extend spread operators to work with numeric
>>> ranges?
>>>
>>> let a = [ 0 ... 3 ];
>>> // Expands to: [ 0, 1, 2, 3 ]
>>>
>>> This wouldn't be a groundbreaking feature, but it would allow better
>>> readability when plotting a range of values:
>>>
>>> let esVersions = [ 1 ... 5, 2015 ];
>>>
>>> It might also be used to extract a range of values:
>>>
>>> array[ 3 ... 6 ] = "ABCDEFGH";
>>> // [ "D", "E", "F", "G" ]
>>>
>>> Which I find far more readable than this:
>>>
>>> array[ , , , , 3, 4, 5, 6 ] = "ABCDEFGH";
>>>
>>> Since it would require two numbers to be explicitly supplied on each
>>> side, there's no risk of it being misinterpreted as an attempt to spread an
>>> array. Decimal components would be dropped:
>>>
>>>

Re: Extending spread operators to work with numbers

[John Gardner]

The range operator wouldn't attempt to fill every duty that a Python-like
`range` function would. I'd envision it being kept intentionally simple (no
custom steps, for example). It looks like what it does, and there's no
reason the two couldn't co-exist.

*can't make mistake (consider [a...b] vs. [a,...b] - is it easy to see
> difference?)*


That's a non-argument pertaining to an author's formatting choice.


On 24 January 2016 at 23:13, Michał Wadas <michalwa...@gmail.com> wrote:

> I want to ask why new syntax would be better than Python-like `range`
> function?
>
> Cons of range:
> - normal function rather than new syntax
> - can be used as memory efficient generator
> - custom step can be defined
> - easy to polyfill
> - can't make mistake (consider [a...b] vs. [a,...b] - is it easy to see
> difference?)
>
> Disadvantages:
> - longer than custom syntax
> On 24 Jan 2016 7:11 am, "John Gardner" <gardnerjo...@gmail.com> wrote:
>
>> *This has all the benefits you seek, including visual clarity, without
>>> overloading the meaning of an existing token.*
>>
>>
>> Actually, I beg to differ. Recall that this is valid syntax:
>>
>> 1.. toString(16);
>>
>> Furthermore, maintaining a 3-dot notation stays consistent with the rest
>> and spread operators, both of which already overload each other. For sake
>> of clarity for this discussion, I'll call this one the "range operator".
>>
>>
>> *I think this is one of those issues where the benefit of any new syntax
>>> here does not pay for its complexity costs.*
>>
>>
>> I don't foresee this raising any complexity issues. The syntax is
>> intended chiefly as a way to specify multiple integer ranges where indexed
>> access is relevant. There wouldn't be any need to specify exclusive or
>> inclusive expansion, because it'd always work inclusively. Which is what I
>> believe every author would expect when they write 1 ... 5.
>>
>> It would also enable one to write this:
>>
>> func( 0 ... 5 )
>>
>> Instead of this:
>>
>> func( ...[0, 1, 2, 3, 4, 5] );
>>
>>
>> I can't speak on anybody else's behalf, but I know which of the two I'd
>> prefer writing.
>>
>> Again, I'll state I don't expect this to be a groundbreaking feature. But
>> it's simple, clean and (from what I understand) would be unintrusive to the
>> language.
>>
>> On 24 January 2016 at 05:41, Mark S. Miller <erig...@google.com> wrote:
>>
>>> The double dot ("..") is the traditional infix operator for
>>> inclusive,inclusive integer ranges, going back to Pascal (the language, not
>>> the mathematician). This has all the benefits you seek, including visual
>>> clarity, without overloading the meaning of an existing token.
>>>
>>> Whether double or triple dot, the problem is that programming patterns
>>> in zero-index-origin languages want inclusive,exclusive ranges, which
>>> naturally wants an asymmetric syntax to suggest the distinction. The
>>> traditional math notation [0, 4) would be unambiguous, since of course we
>>> never otherwise allow a closing paren to match an opening square bracket.
>>> But, in a programming language context I find it too jarring.
>>>
>>> E has ".." for inclusive,inclusive ranges, just like Pascal. E also has
>>> "..!" for inclusive,exclusive ranges. The second operator was used much
>>> more than the first. I don't think "..!" is great but I don't have anything
>>> better to suggest.
>>>
>>> Finally, we must ask whether this problem is worth solving with any
>>> syntax or at all. We can already express these well enough with APIs. I
>>> think this is one of those issues where the benefit of any new syntax here
>>> does not pay for its complexity costs. See *The Tragedy of the Common
>>> Lisp, or, Why Large Languages Explode* <
>>> https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks
>>> >.
>>>
>>> See also <https://en.wikipedia.org/wiki/Primum_non_nocere>.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jan 22, 2016 at 10:20 PM, John Gardner <gardnerjo...@gmail.com>
>>> wrote:
>>>
>>>> Probably a stupid idea, and I can see it already being brought up
>>>> several times... but why not extend spread operators to work with numeric
>>>> ranges?
>>>>
>>>> let a = [ 0 ... 3

Re: Extending spread operators to work with numbers

[kdex]

Just a quick idea: The range operator could also be used for non-numeric 
ranges:

```js
let latin = ["a" ... "z"];
// ["a", "b", "c", ..., "x", "y", "z"]
let latinBackwards = ["z" ... "a"];
// ["z", "y", "x", ..., "c", "b", "a"]
let emoji = ["\u{1F601}" ... "\u{1F64F}"]
// ["\u{1F601}", "\u{1F602}", …, "\u{1F64E}", "\u{1F64F}"]
```

On Sonntag, 24. Januar 2016 23:25:35 CET John Gardner wrote:
> The range operator wouldn't attempt to fill every duty that a Python-like
> `range` function would. I'd envision it being kept intentionally simple (no
> custom steps, for example). It looks like what it does, and there's no
> reason the two couldn't co-exist.
> 
> *can't make mistake (consider [a...b] vs. [a,...b] - is it easy to see
> 
> > difference?)*
> 
> That's a non-argument pertaining to an author's formatting choice.
> 
> On 24 January 2016 at 23:13, Michał Wadas <michalwa...@gmail.com> wrote:
> > I want to ask why new syntax would be better than Python-like `range`
> > function?
> > 
> > Cons of range:
> > - normal function rather than new syntax
> > - can be used as memory efficient generator
> > - custom step can be defined
> > - easy to polyfill
> > - can't make mistake (consider [a...b] vs. [a,...b] - is it easy to see
> > difference?)
> > 
> > Disadvantages:
> > - longer than custom syntax
> > 
> > On 24 Jan 2016 7:11 am, "John Gardner" <gardnerjo...@gmail.com> wrote:
> >> *This has all the benefits you seek, including visual clarity, without
> >> 
> >>> overloading the meaning of an existing token.*
> >> 
> >> Actually, I beg to differ. Recall that this is valid syntax:
> >> 
> >> 1.. toString(16);
> >> 
> >> Furthermore, maintaining a 3-dot notation stays consistent with the rest
> >> and spread operators, both of which already overload each other. For sake
> >> of clarity for this discussion, I'll call this one the "range operator".
> >> 
> >> 
> >> *I think this is one of those issues where the benefit of any new syntax
> >> 
> >>> here does not pay for its complexity costs.*
> >> 
> >> I don't foresee this raising any complexity issues. The syntax is
> >> intended chiefly as a way to specify multiple integer ranges where
> >> indexed
> >> access is relevant. There wouldn't be any need to specify exclusive or
> >> inclusive expansion, because it'd always work inclusively. Which is what
> >> I
> >> believe every author would expect when they write 1 ... 5.
> >> 
> >> It would also enable one to write this:
> >> 
> >> func( 0 ... 5 )
> >> 
> >> Instead of this:
> >> 
> >> func( ...[0, 1, 2, 3, 4, 5] );
> >> 
> >> 
> >> I can't speak on anybody else's behalf, but I know which of the two I'd
> >> prefer writing.
> >> 
> >> Again, I'll state I don't expect this to be a groundbreaking feature. But
> >> it's simple, clean and (from what I understand) would be unintrusive to
> >> the
> >> language.
> >> 
> >> On 24 January 2016 at 05:41, Mark S. Miller <erig...@google.com> wrote:
> >>> The double dot ("..") is the traditional infix operator for
> >>> inclusive,inclusive integer ranges, going back to Pascal (the language,
> >>> not
> >>> the mathematician). This has all the benefits you seek, including visual
> >>> clarity, without overloading the meaning of an existing token.
> >>> 
> >>> Whether double or triple dot, the problem is that programming patterns
> >>> in zero-index-origin languages want inclusive,exclusive ranges, which
> >>> naturally wants an asymmetric syntax to suggest the distinction. The
> >>> traditional math notation [0, 4) would be unambiguous, since of course
> >>> we
> >>> never otherwise allow a closing paren to match an opening square
> >>> bracket.
> >>> But, in a programming language context I find it too jarring.
> >>> 
> >>> E has ".." for inclusive,inclusive ranges, just like Pascal. E also has
> >>> "..!" for inclusive,exclusive ranges. The second operator was used much
> >>> more than the first. I don't think "..!" is great but I don't have
> &g

Re: Extending spread operators to work with numbers

[Mark S. Miller]

The double dot ("..") is the traditional infix operator for
inclusive,inclusive integer ranges, going back to Pascal (the language, not
the mathematician). This has all the benefits you seek, including visual
clarity, without overloading the meaning of an existing token.

Whether double or triple dot, the problem is that programming patterns in
zero-index-origin languages want inclusive,exclusive ranges, which
naturally wants an asymmetric syntax to suggest the distinction. The
traditional math notation [0, 4) would be unambiguous, since of course we
never otherwise allow a closing paren to match an opening square bracket.
But, in a programming language context I find it too jarring.

E has ".." for inclusive,inclusive ranges, just like Pascal. E also has
"..!" for inclusive,exclusive ranges. The second operator was used much
more than the first. I don't think "..!" is great but I don't have anything
better to suggest.

Finally, we must ask whether this problem is worth solving with any syntax
or at all. We can already express these well enough with APIs. I think this
is one of those issues where the benefit of any new syntax here does not
pay for its complexity costs. See *The Tragedy of the Common Lisp, or, Why
Large Languages Explode* <
https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks
>.

See also <https://en.wikipedia.org/wiki/Primum_non_nocere>.






On Fri, Jan 22, 2016 at 10:20 PM, John Gardner <gardnerjo...@gmail.com>
wrote:

> Probably a stupid idea, and I can see it already being brought up several
> times... but why not extend spread operators to work with numeric ranges?
>
> let a = [ 0 ... 3 ];
> // Expands to: [ 0, 1, 2, 3 ]
>
> This wouldn't be a groundbreaking feature, but it would allow better
> readability when plotting a range of values:
>
> let esVersions = [ 1 ... 5, 2015 ];
>
> It might also be used to extract a range of values:
>
> array[ 3 ... 6 ] = "ABCDEFGH";
> // [ "D", "E", "F", "G" ]
>
> Which I find far more readable than this:
>
> array[ , , , , 3, 4, 5, 6 ] = "ABCDEFGH";
>
> Since it would require two numbers to be explicitly supplied on each side,
> there's no risk of it being misinterpreted as an attempt to spread an
> array. Decimal components would be dropped:
>
> let a = [ 1 ... 3.9 ];
> // [ 1, 2, 3 ]
>
> This would complement Alican's suggested syntax for slicing an array of
> values, which modifies the original array.
>
> Thoughts? Just throwing crap out there.
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extending spread operators to work with numbers

[John Gardner]

>
> *This has all the benefits you seek, including visual clarity, without
> overloading the meaning of an existing token.*


Actually, I beg to differ. Recall that this is valid syntax:

1.. toString(16);

Furthermore, maintaining a 3-dot notation stays consistent with the rest
and spread operators, both of which already overload each other. For sake
of clarity for this discussion, I'll call this one the "range operator".


*I think this is one of those issues where the benefit of any new syntax
> here does not pay for its complexity costs.*


I don't foresee this raising any complexity issues. The syntax is intended
chiefly as a way to specify multiple integer ranges where indexed access is
relevant. There wouldn't be any need to specify exclusive or inclusive
expansion, because it'd always work inclusively. Which is what I believe
every author would expect when they write 1 ... 5.

It would also enable one to write this:

func( 0 ... 5 )

Instead of this:

func( ...[0, 1, 2, 3, 4, 5] );


I can't speak on anybody else's behalf, but I know which of the two I'd
prefer writing.

Again, I'll state I don't expect this to be a groundbreaking feature. But
it's simple, clean and (from what I understand) would be unintrusive to the
language.

On 24 January 2016 at 05:41, Mark S. Miller <erig...@google.com> wrote:

> The double dot ("..") is the traditional infix operator for
> inclusive,inclusive integer ranges, going back to Pascal (the language, not
> the mathematician). This has all the benefits you seek, including visual
> clarity, without overloading the meaning of an existing token.
>
> Whether double or triple dot, the problem is that programming patterns in
> zero-index-origin languages want inclusive,exclusive ranges, which
> naturally wants an asymmetric syntax to suggest the distinction. The
> traditional math notation [0, 4) would be unambiguous, since of course we
> never otherwise allow a closing paren to match an opening square bracket.
> But, in a programming language context I find it too jarring.
>
> E has ".." for inclusive,inclusive ranges, just like Pascal. E also has
> "..!" for inclusive,exclusive ranges. The second operator was used much
> more than the first. I don't think "..!" is great but I don't have anything
> better to suggest.
>
> Finally, we must ask whether this problem is worth solving with any syntax
> or at all. We can already express these well enough with APIs. I think this
> is one of those issues where the benefit of any new syntax here does not
> pay for its complexity costs. See *The Tragedy of the Common Lisp, or,
> Why Large Languages Explode* <
> https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks
> >.
>
> See also <https://en.wikipedia.org/wiki/Primum_non_nocere>.
>
>
>
>
>
>
> On Fri, Jan 22, 2016 at 10:20 PM, John Gardner <gardnerjo...@gmail.com>
> wrote:
>
>> Probably a stupid idea, and I can see it already being brought up several
>> times... but why not extend spread operators to work with numeric ranges?
>>
>> let a = [ 0 ... 3 ];
>> // Expands to: [ 0, 1, 2, 3 ]
>>
>> This wouldn't be a groundbreaking feature, but it would allow better
>> readability when plotting a range of values:
>>
>> let esVersions = [ 1 ... 5, 2015 ];
>>
>> It might also be used to extract a range of values:
>>
>> array[ 3 ... 6 ] = "ABCDEFGH";
>> // [ "D", "E", "F", "G" ]
>>
>> Which I find far more readable than this:
>>
>> array[ , , , , 3, 4, 5, 6 ] = "ABCDEFGH";
>>
>> Since it would require two numbers to be explicitly supplied on each
>> side, there's no risk of it being misinterpreted as an attempt to spread an
>> array. Decimal components would be dropped:
>>
>> let a = [ 1 ... 3.9 ];
>> // [ 1, 2, 3 ]
>>
>> This would complement Alican's suggested syntax for slicing an array of
>> values, which modifies the original array.
>>
>> Thoughts? Just throwing crap out there.
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extending spread operators to work with numbers

[kdex]

You're saying that it has already been brought up; would you mind linking to 
the relevant threads, then?

Other than that, I really like this syntax. Should this also work when the 
range is specified dynamically, and not in terms of number literals? And what 
about parsing it next to a "regular" spread operator?

```js
let a = () => [3];
let b = () => [7];
let string = "Hello, world!";
let range = string[...a() ..b()];
// "lo, w"
```

On Samstag, 23. Januar 2016 17:20:36 CET John Gardner wrote:
> Probably a stupid idea, and I can see it already being brought up several
> times... but why not extend spread operators to work with numeric ranges?
> 
> let a = [ 0 ... 3 ];
> // Expands to: [ 0, 1, 2, 3 ]
> 
> This wouldn't be a groundbreaking feature, but it would allow better
> readability when plotting a range of values:
> 
> let esVersions = [ 1 ... 5, 2015 ];
> 
> It might also be used to extract a range of values:
> 
> array[ 3 ... 6 ] = "ABCDEFGH";
> // [ "D", "E", "F", "G" ]
> 
> Which I find far more readable than this:
> 
> array[ , , , , 3, 4, 5, 6 ] = "ABCDEFGH";
> 
> Since it would require two numbers to be explicitly supplied on each side,
> there's no risk of it being misinterpreted as an attempt to spread an
> array. Decimal components would be dropped:
> 
> let a = [ 1 ... 3.9 ];
> // [ 1, 2, 3 ]
> 
> This would complement Alican's suggested syntax for slicing an array of
> values, which modifies the original array.
> 
> Thoughts? Just throwing crap out there.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extending spread operators to work with numbers

[John Gardner]

Heh, I said it's *probably* been brought up.

*> Should this also work when the range is specified dynamically, and not
in terms of number literals?*

Certainly. Each value around the spread operator would be coerced to an
integer, following the standard pattern of numeric evaluation. Then the
decimal component, if any, would be ignored, and the resulting value used.

*> And what about parsing it next to a "regular" spread operator?*

"Regular" spread operators should take precedence. The order of evaluation
would be like this:

let range = [ ...[1, 3] ... ...[6, 7] ];
// ->   [1, 3 ... 6, 7];
// ->   [1, 3, 4, 5, 6, 7];

On 23 January 2016 at 18:49, kdex <k...@kdex.de> wrote:

> You're saying that it has already been brought up; would you mind linking
> to
> the relevant threads, then?
>
> Other than that, I really like this syntax. Should this also work when the
> range is specified dynamically, and not in terms of number literals? And
> what
> about parsing it next to a "regular" spread operator?
>
> ```js
> let a = () => [3];
> let b = () => [7];
> let string = "Hello, world!";
> let range = string[...a() ..b()];
> // "lo, w"
> ```
>
> On Samstag, 23. Januar 2016 17:20:36 CET John Gardner wrote:
> > Probably a stupid idea, and I can see it already being brought up several
> > times... but why not extend spread operators to work with numeric ranges?
> >
> > let a = [ 0 ... 3 ];
> > // Expands to: [ 0, 1, 2, 3 ]
> >
> > This wouldn't be a groundbreaking feature, but it would allow better
> > readability when plotting a range of values:
> >
> > let esVersions = [ 1 ... 5, 2015 ];
> >
> > It might also be used to extract a range of values:
> >
> > array[ 3 ... 6 ] = "ABCDEFGH";
> > // [ "D", "E", "F", "G" ]
> >
> > Which I find far more readable than this:
> >
> > array[ , , , , 3, 4, 5, 6 ] = "ABCDEFGH";
> >
> > Since it would require two numbers to be explicitly supplied on each
> side,
> > there's no risk of it being misinterpreted as an attempt to spread an
> > array. Decimal components would be dropped:
> >
> > let a = [ 1 ... 3.9 ];
> > // [ 1, 2, 3 ]
> >
> > This would complement Alican's suggested syntax for slicing an array of
> > values, which modifies the original array.
> >
> > Thoughts? Just throwing crap out there.
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Extending spread operators to work with numbers

[John Gardner]

Probably a stupid idea, and I can see it already being brought up several
times... but why not extend spread operators to work with numeric ranges?

let a = [ 0 ... 3 ];
// Expands to: [ 0, 1, 2, 3 ]

This wouldn't be a groundbreaking feature, but it would allow better
readability when plotting a range of values:

let esVersions = [ 1 ... 5, 2015 ];

It might also be used to extract a range of values:

array[ 3 ... 6 ] = "ABCDEFGH";
// [ "D", "E", "F", "G" ]

Which I find far more readable than this:

array[ , , , , 3, 4, 5, 6 ] = "ABCDEFGH";

Since it would require two numbers to be explicitly supplied on each side,
there's no risk of it being misinterpreted as an attempt to spread an
array. Decimal components would be dropped:

let a = [ 1 ... 3.9 ];
// [ 1, 2, 3 ]

This would complement Alican's suggested syntax for slicing an array of
values, which modifies the original array.

Thoughts? Just throwing crap out there.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re[2]: Operators overriding

[Isiah Meadows]

That's almost implementing its own runtime system just to emulate operator
overloading, to be honest.

On Mon, Dec 28, 2015, 17:10 /#!/JoePea  wrote:

> I just read this interesting article:
> http://www.2ality.com/2011/12/fake-operator-overloading.html?m=1
>
> Wow. What iteresting "fake" overloading. Check out the `new Point(1,
> 2) + new Point(3, 4) + new Point(5, 6)` example.
>
> On Mon, Dec 28, 2015 at 11:36 AM, Sander Deryckere 
> wrote:
> > There are so many places where overloading would be useful., even between
> > different data types:
> >
> > * adding vectors
> > * multiplying vectors with matrices
> > * multiplying vectors with numbers
> > * multiplying or adding matrices
> > * adding (or subtracting) date objects (to get a time difference)
> >
> > Certainly in the case of working with vectors, you often need long
> > calculations with intermediate results. In those cases, it's also often
> > convenient to use short names (as the names are very local). So while
> > myFirstMatrix.multiply(mySecondMatrix) is acceptable, m1.multiply(m2)
> isn't
> > so acceptable. it distracts your attention too much to the name
> "multiply"
> > instead of letting you see the math behind it.
> >
> > I like JavaScript as a versatile language. It really gives the programmer
> > the responsibility to write good code. Of course you can write bad code
> with
> > operation overloading, but you can also write bad code now.
> >
> > Regards,
> > Sander
> >
> >
> > 2015-12-28 19:45 GMT+01:00 /#!/JoePea :
> >>
> >> I'm kind of on the fence about it. `let result =
> >> matrix1.multiply(matrix2)` works for graphics, but `var result =
> >> matrix1 * matrix2` could be nice.
> >>
> >> Now that I think about it, I think I'll fall over onto the +1 side of
> >> the fence, because one of the things I love about JavaScript is how
> >> flexible it is as a language, and this adds to that flexibility that
> >> developers have in choosing how they write code.
> >>
> >> On Mon, Dec 28, 2015 at 10:26 AM, Coroutines 
> wrote:
> >> > On Mon, Dec 28, 2015 at 9:55 AM, Bradley Meck  >
> >> > wrote:
> >> >> Who would think not knowing what `a+b` could do as a pitfall? /s
> >> >>
> >> >> I am not a big fan of overloading though, since it presents more
> mental
> >> >> complexity as they map to functions without looking like function
> >> >> calls.
> >> >
> >> > From the Wikipedia page on ecmascript it seemed like operator
> >> > overloading was already a for-sure planned feature of ES7, just not
> >> > fleshed out in a spec.  I personally do love operator overloading - I
> >> > am used to it from Lua and Python and I think it can be quite nice.
> >> > Especially for making PEG combinator stuff:
> >> >
> >> > term = Any(1) // any 1 character
> >> > whitespace = Range(CharSet(' \t'), 1, Infinity) // space or tab,
> >> > repeated 1 or more times
> >> > indented_term = whitespace + term // will match: '  x'
> >> >
> >> > result = indented_term.parse('text...')
> >> >
> >> > Okay this is a bad example.  But when you're building a grammar
> >> > description from objects it can be quite fun to make use of operator
> >> > overloading for a much cleaner description - somewhat like a
> >> > domain-specific language (DSL) within JS.  LPeg in Lua and PyPeg in
> >> > Python make this rather pleasant.
> >> >
> >> > Anyway, I suspect it won't matter what syntactic features Javascript
> >> > gains once WebAssembly gets adopted.  We already have the fundamentals
> >> > like inheritance in place so that any language can compile to a
> >> > WebAssembly AST and run as one would expect.
> >> > ___
> >> > es-discuss mailing list
> >> > es-discuss@mozilla.org
> >> > https://mail.mozilla.org/listinfo/es-discuss
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re[2]: Operators overriding

[Nicolas B. Pierron]

This is right, currently code such as "asm js" rely on "a | 0" and
"+a" to force a type interpretation. Having an override means that we
would have to guard explicitly against overridden the operator before
entering these sections of code.
This will increase the cost of cold calls.  If this is a frequent
path, then we would have to infer the type as long as possible to
remove such guards.

Currently, proxies have more important issues in SpiderMonkey, as they
allow to instrument the lookup of properties (which is still in C++)
in a side-effectful way.

On Sun, Dec 27, 2015 at 9:42 PM, Frankie Bagnardi <f.bagna...@gmail.com> wrote:
> Generally letting proxies do more things is a good thing, but what would be
> the cost in optimizing JITs? It seems like e.g. making `a + b` or `a | 0`
> more flexible would also make them slower.  Is this incorrect?
>
> On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH <kola...@mail.ru> wrote:
>>
>> I dislike this proposal.
>> 1 It is not very good to limit overrideable operators to value classes.
>> 2 It is not very good to have a lot of custom operators, it will break
>> code readability and will allow more efficient obfuscration.
>> 3 I think that most of binary non-assigning operators must return a new
>> object and thats' why they should be not object methods, but the methods
>> taking 2 (or more if chained!) objects and return the result usually of same
>> type.
>>
>> вторник, 22 декабря 2015г., 21:45 +03:00 от Sander Deryckere
>> <sander...@gmail.com>:
>>
>>
>> IMO, operator overloading is important and different enough to warrant a
>> separate syntax.
>>
>> But the difficulty isn't in defining the operator, but in the ambiguous
>> cases. Like what to do when there are 2 different types, how to make sure
>> certain relations will stay correct, ...
>>
>> There's a nice presentation from Brendan Eich here:
>> http://www.slideshare.net/BrendanEich/value-objects2
>>
>> Regards,
>> Sander
>>
>> 2015-12-18 21:24 GMT+01:00 KOLANICH <kola...@mail.ru>:
>>
>> Hello. What do you think about overriding operators using proxies?
>>
>> For example
>> function A(r=""){
>> this.rep=r;
>> return new Proxy(this,{operators:{"+":function(a,b){return new
>> A(a.rep+"+"+b.rep);}}});
>> }
>> let a=new A("a"), b=new A("b");
>> let c=a+b;
>> console.log(c.rep);//a+b
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Nicolas B. Pierron
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re[2]: Operators overriding

[Bradley Meck]

Who would think not knowing what `a+b` could do as a pitfall? /s

I am not a big fan of overloading though, since it presents more mental
complexity as they map to functions without looking like function calls.

On Mon, Dec 28, 2015 at 11:52 AM, Alexander Jones <a...@weej.com> wrote:

> Who would have thought using completely un-semantic idioms such as |0 and
> !! would lead to issues down the line? /s
>
> On 28 December 2015 at 14:50, Nicolas B. Pierron <
> nicolas.b.pier...@mozilla.com> wrote:
>
>> This is right, currently code such as "asm js" rely on "a | 0" and
>> "+a" to force a type interpretation. Having an override means that we
>> would have to guard explicitly against overridden the operator before
>> entering these sections of code.
>> This will increase the cost of cold calls.  If this is a frequent
>> path, then we would have to infer the type as long as possible to
>> remove such guards.
>>
>> Currently, proxies have more important issues in SpiderMonkey, as they
>> allow to instrument the lookup of properties (which is still in C++)
>> in a side-effectful way.
>>
>> On Sun, Dec 27, 2015 at 9:42 PM, Frankie Bagnardi <f.bagna...@gmail.com>
>> wrote:
>> > Generally letting proxies do more things is a good thing, but what
>> would be
>> > the cost in optimizing JITs? It seems like e.g. making `a + b` or `a |
>> 0`
>> > more flexible would also make them slower.  Is this incorrect?
>> >
>> > On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH <kola...@mail.ru> wrote:
>> >>
>> >> I dislike this proposal.
>> >> 1 It is not very good to limit overrideable operators to value classes.
>> >> 2 It is not very good to have a lot of custom operators, it will break
>> >> code readability and will allow more efficient obfuscration.
>> >> 3 I think that most of binary non-assigning operators must return a new
>> >> object and thats' why they should be not object methods, but the
>> methods
>> >> taking 2 (or more if chained!) objects and return the result usually
>> of same
>> >> type.
>> >>
>> >> вторник, 22 декабря 2015г., 21:45 +03:00 от Sander Deryckere
>> >> <sander...@gmail.com>:
>> >>
>> >>
>> >> IMO, operator overloading is important and different enough to warrant
>> a
>> >> separate syntax.
>> >>
>> >> But the difficulty isn't in defining the operator, but in the ambiguous
>> >> cases. Like what to do when there are 2 different types, how to make
>> sure
>> >> certain relations will stay correct, ...
>> >>
>> >> There's a nice presentation from Brendan Eich here:
>> >> http://www.slideshare.net/BrendanEich/value-objects2
>> >>
>> >> Regards,
>> >> Sander
>> >>
>> >> 2015-12-18 21:24 GMT+01:00 KOLANICH <kola...@mail.ru>:
>> >>
>> >> Hello. What do you think about overriding operators using proxies?
>> >>
>> >> For example
>> >> function A(r=""){
>> >> this.rep=r;
>> >> return new Proxy(this,{operators:{"+":function(a,b){return new
>> >> A(a.rep+"+"+b.rep);}}});
>> >> }
>> >> let a=new A("a"), b=new A("b");
>> >> let c=a+b;
>> >> console.log(c.rep);//a+b
>> >>
>> >>
>> >> ___
>> >> es-discuss mailing list
>> >> es-discuss@mozilla.org
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >>
>> >>
>> >> ___
>> >> es-discuss mailing list
>> >> es-discuss@mozilla.org
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >
>> >
>> > ___
>> > es-discuss mailing list
>> > es-discuss@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>>
>>
>>
>> --
>> Nicolas B. Pierron
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re[2]: Operators overriding

[Alexander Jones]

Who would have thought using completely un-semantic idioms such as |0 and
!! would lead to issues down the line? /s

On 28 December 2015 at 14:50, Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:

> This is right, currently code such as "asm js" rely on "a | 0" and
> "+a" to force a type interpretation. Having an override means that we
> would have to guard explicitly against overridden the operator before
> entering these sections of code.
> This will increase the cost of cold calls.  If this is a frequent
> path, then we would have to infer the type as long as possible to
> remove such guards.
>
> Currently, proxies have more important issues in SpiderMonkey, as they
> allow to instrument the lookup of properties (which is still in C++)
> in a side-effectful way.
>
> On Sun, Dec 27, 2015 at 9:42 PM, Frankie Bagnardi <f.bagna...@gmail.com>
> wrote:
> > Generally letting proxies do more things is a good thing, but what would
> be
> > the cost in optimizing JITs? It seems like e.g. making `a + b` or `a | 0`
> > more flexible would also make them slower.  Is this incorrect?
> >
> > On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH <kola...@mail.ru> wrote:
> >>
> >> I dislike this proposal.
> >> 1 It is not very good to limit overrideable operators to value classes.
> >> 2 It is not very good to have a lot of custom operators, it will break
> >> code readability and will allow more efficient obfuscration.
> >> 3 I think that most of binary non-assigning operators must return a new
> >> object and thats' why they should be not object methods, but the methods
> >> taking 2 (or more if chained!) objects and return the result usually of
> same
> >> type.
> >>
> >> вторник, 22 декабря 2015г., 21:45 +03:00 от Sander Deryckere
> >> <sander...@gmail.com>:
> >>
> >>
> >> IMO, operator overloading is important and different enough to warrant a
> >> separate syntax.
> >>
> >> But the difficulty isn't in defining the operator, but in the ambiguous
> >> cases. Like what to do when there are 2 different types, how to make
> sure
> >> certain relations will stay correct, ...
> >>
> >> There's a nice presentation from Brendan Eich here:
> >> http://www.slideshare.net/BrendanEich/value-objects2
> >>
> >> Regards,
> >> Sander
> >>
> >> 2015-12-18 21:24 GMT+01:00 KOLANICH <kola...@mail.ru>:
> >>
> >> Hello. What do you think about overriding operators using proxies?
> >>
> >> For example
> >> function A(r=""){
> >> this.rep=r;
> >> return new Proxy(this,{operators:{"+":function(a,b){return new
> >> A(a.rep+"+"+b.rep);}}});
> >> }
> >> let a=new A("a"), b=new A("b");
> >> let c=a+b;
> >> console.log(c.rep);//a+b
> >>
> >>
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >>
> >>
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
> --
> Nicolas B. Pierron
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re[2]: Operators overriding

[Alexander Jones]

Regarding not knowing what `a + b` does: you *already* don't know because
it invokes `.valueOf`. If you already know the operands are typeof
"number", you're good to optimise just as much as with operator overloading.

Aside from that, we're back into arguments about the clarity benefits of

 * paren-free function invocation
 * non-member, postfix function call syntax, aka `::`

And finally, any discussion about the perceived "mental tax" of operators
would be incomplete without a reference to the definition of the `+`
operator in ECMAScript 2016[1]. Ever tried explaining to beginners what the
result of `[] + {}` is, while keeping a straight face?

1.
http://www.ecma-international.org/ecma-262/6.0/#sec-addition-operator-plus

On 28 December 2015 at 17:59, /#!/JoePea <j...@trusktr.io> wrote:

> I'm in favor of no overloading for the reason of the mental tax.
> People could write a program where everything is a mathematical
> operation (in looks, not necessarily functionality), which could
> encourage harder-to-read code. I think `this.plus(that)` is fine for
> objects. With a proper auto-completing editor, this really isn't that
> difficult. Plus, there's Sweet.js if you really want it.
>
> On Mon, Dec 28, 2015 at 9:55 AM, Bradley Meck <bradley.m...@gmail.com>
> wrote:
> > Who would think not knowing what `a+b` could do as a pitfall? /s
> >
> > I am not a big fan of overloading though, since it presents more mental
> > complexity as they map to functions without looking like function calls.
> >
> > On Mon, Dec 28, 2015 at 11:52 AM, Alexander Jones <a...@weej.com> wrote:
> >>
> >> Who would have thought using completely un-semantic idioms such as |0
> and
> >> !! would lead to issues down the line? /s
> >>
> >> On 28 December 2015 at 14:50, Nicolas B. Pierron
> >> <nicolas.b.pier...@mozilla.com> wrote:
> >>>
> >>> This is right, currently code such as "asm js" rely on "a | 0" and
> >>> "+a" to force a type interpretation. Having an override means that we
> >>> would have to guard explicitly against overridden the operator before
> >>> entering these sections of code.
> >>> This will increase the cost of cold calls.  If this is a frequent
> >>> path, then we would have to infer the type as long as possible to
> >>> remove such guards.
> >>>
> >>> Currently, proxies have more important issues in SpiderMonkey, as they
> >>> allow to instrument the lookup of properties (which is still in C++)
> >>> in a side-effectful way.
> >>>
> >>> On Sun, Dec 27, 2015 at 9:42 PM, Frankie Bagnardi <
> f.bagna...@gmail.com>
> >>> wrote:
> >>> > Generally letting proxies do more things is a good thing, but what
> >>> > would be
> >>> > the cost in optimizing JITs? It seems like e.g. making `a + b` or `a
> |
> >>> > 0`
> >>> > more flexible would also make them slower.  Is this incorrect?
> >>> >
> >>> > On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH <kola...@mail.ru> wrote:
> >>> >>
> >>> >> I dislike this proposal.
> >>> >> 1 It is not very good to limit overrideable operators to value
> >>> >> classes.
> >>> >> 2 It is not very good to have a lot of custom operators, it will
> break
> >>> >> code readability and will allow more efficient obfuscration.
> >>> >> 3 I think that most of binary non-assigning operators must return a
> >>> >> new
> >>> >> object and thats' why they should be not object methods, but the
> >>> >> methods
> >>> >> taking 2 (or more if chained!) objects and return the result usually
> >>> >> of same
> >>> >> type.
> >>> >>
> >>> >> вторник, 22 декабря 2015г., 21:45 +03:00 от Sander Deryckere
> >>> >> <sander...@gmail.com>:
> >>> >>
> >>> >>
> >>> >> IMO, operator overloading is important and different enough to
> warrant
> >>> >> a
> >>> >> separate syntax.
> >>> >>
> >>> >> But the difficulty isn't in defining the operator, but in the
> >>> >> ambiguous
> >>> >> cases. Like what to do when there are 2 different types, how to make
> >>> >> sure
> >>> >> certain relations will stay correct, ...
> >>> >&g

Re: Re[2]: Operators overriding

[/#!/JoePea]

I'm in favor of no overloading for the reason of the mental tax.
People could write a program where everything is a mathematical
operation (in looks, not necessarily functionality), which could
encourage harder-to-read code. I think `this.plus(that)` is fine for
objects. With a proper auto-completing editor, this really isn't that
difficult. Plus, there's Sweet.js if you really want it.

On Mon, Dec 28, 2015 at 9:55 AM, Bradley Meck <bradley.m...@gmail.com> wrote:
> Who would think not knowing what `a+b` could do as a pitfall? /s
>
> I am not a big fan of overloading though, since it presents more mental
> complexity as they map to functions without looking like function calls.
>
> On Mon, Dec 28, 2015 at 11:52 AM, Alexander Jones <a...@weej.com> wrote:
>>
>> Who would have thought using completely un-semantic idioms such as |0 and
>> !! would lead to issues down the line? /s
>>
>> On 28 December 2015 at 14:50, Nicolas B. Pierron
>> <nicolas.b.pier...@mozilla.com> wrote:
>>>
>>> This is right, currently code such as "asm js" rely on "a | 0" and
>>> "+a" to force a type interpretation. Having an override means that we
>>> would have to guard explicitly against overridden the operator before
>>> entering these sections of code.
>>> This will increase the cost of cold calls.  If this is a frequent
>>> path, then we would have to infer the type as long as possible to
>>> remove such guards.
>>>
>>> Currently, proxies have more important issues in SpiderMonkey, as they
>>> allow to instrument the lookup of properties (which is still in C++)
>>> in a side-effectful way.
>>>
>>> On Sun, Dec 27, 2015 at 9:42 PM, Frankie Bagnardi <f.bagna...@gmail.com>
>>> wrote:
>>> > Generally letting proxies do more things is a good thing, but what
>>> > would be
>>> > the cost in optimizing JITs? It seems like e.g. making `a + b` or `a |
>>> > 0`
>>> > more flexible would also make them slower.  Is this incorrect?
>>> >
>>> > On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH <kola...@mail.ru> wrote:
>>> >>
>>> >> I dislike this proposal.
>>> >> 1 It is not very good to limit overrideable operators to value
>>> >> classes.
>>> >> 2 It is not very good to have a lot of custom operators, it will break
>>> >> code readability and will allow more efficient obfuscration.
>>> >> 3 I think that most of binary non-assigning operators must return a
>>> >> new
>>> >> object and thats' why they should be not object methods, but the
>>> >> methods
>>> >> taking 2 (or more if chained!) objects and return the result usually
>>> >> of same
>>> >> type.
>>> >>
>>> >> вторник, 22 декабря 2015г., 21:45 +03:00 от Sander Deryckere
>>> >> <sander...@gmail.com>:
>>> >>
>>> >>
>>> >> IMO, operator overloading is important and different enough to warrant
>>> >> a
>>> >> separate syntax.
>>> >>
>>> >> But the difficulty isn't in defining the operator, but in the
>>> >> ambiguous
>>> >> cases. Like what to do when there are 2 different types, how to make
>>> >> sure
>>> >> certain relations will stay correct, ...
>>> >>
>>> >> There's a nice presentation from Brendan Eich here:
>>> >> http://www.slideshare.net/BrendanEich/value-objects2
>>> >>
>>> >> Regards,
>>> >> Sander
>>> >>
>>> >> 2015-12-18 21:24 GMT+01:00 KOLANICH <kola...@mail.ru>:
>>> >>
>>> >> Hello. What do you think about overriding operators using proxies?
>>> >>
>>> >> For example
>>> >> function A(r=""){
>>> >> this.rep=r;
>>> >> return new Proxy(this,{operators:{"+":function(a,b){return new
>>> >> A(a.rep+"+"+b.rep);}}});
>>> >> }
>>> >> let a=new A("a"), b=new A("b");
>>> >> let c=a+b;
>>> >> console.log(c.rep);//a+b
>>> >>
>>> >>
>>> >> ___
>>> >> es-discuss mailing list
>>> >> es-discuss@mozilla.org
>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>> >>
>>> >>
>>> >>
>>> >> ___
>>> >> es-discuss mailing list
>>> >> es-discuss@mozilla.org
>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>> >>
>>> >
>>> >
>>> > ___
>>> > es-discuss mailing list
>>> > es-discuss@mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>>
>>>
>>>
>>> --
>>> Nicolas B. Pierron
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re[2]: Operators overriding

[/#!/JoePea]

On Mon, Dec 28, 2015 at 10:19 AM, Alexander Jones  wrote:
> `[] + {}`

That's an odd use case. I've never used it myself. Straight face not
possible. x]
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re[2]: Operators overriding

[/#!/JoePea]

I just read this interesting article:
http://www.2ality.com/2011/12/fake-operator-overloading.html?m=1

Wow. What iteresting "fake" overloading. Check out the `new Point(1,
2) + new Point(3, 4) + new Point(5, 6)` example.

On Mon, Dec 28, 2015 at 11:36 AM, Sander Deryckere  wrote:
> There are so many places where overloading would be useful., even between
> different data types:
>
> * adding vectors
> * multiplying vectors with matrices
> * multiplying vectors with numbers
> * multiplying or adding matrices
> * adding (or subtracting) date objects (to get a time difference)
>
> Certainly in the case of working with vectors, you often need long
> calculations with intermediate results. In those cases, it's also often
> convenient to use short names (as the names are very local). So while
> myFirstMatrix.multiply(mySecondMatrix) is acceptable, m1.multiply(m2) isn't
> so acceptable. it distracts your attention too much to the name "multiply"
> instead of letting you see the math behind it.
>
> I like JavaScript as a versatile language. It really gives the programmer
> the responsibility to write good code. Of course you can write bad code with
> operation overloading, but you can also write bad code now.
>
> Regards,
> Sander
>
>
> 2015-12-28 19:45 GMT+01:00 /#!/JoePea :
>>
>> I'm kind of on the fence about it. `let result =
>> matrix1.multiply(matrix2)` works for graphics, but `var result =
>> matrix1 * matrix2` could be nice.
>>
>> Now that I think about it, I think I'll fall over onto the +1 side of
>> the fence, because one of the things I love about JavaScript is how
>> flexible it is as a language, and this adds to that flexibility that
>> developers have in choosing how they write code.
>>
>> On Mon, Dec 28, 2015 at 10:26 AM, Coroutines  wrote:
>> > On Mon, Dec 28, 2015 at 9:55 AM, Bradley Meck 
>> > wrote:
>> >> Who would think not knowing what `a+b` could do as a pitfall? /s
>> >>
>> >> I am not a big fan of overloading though, since it presents more mental
>> >> complexity as they map to functions without looking like function
>> >> calls.
>> >
>> > From the Wikipedia page on ecmascript it seemed like operator
>> > overloading was already a for-sure planned feature of ES7, just not
>> > fleshed out in a spec.  I personally do love operator overloading - I
>> > am used to it from Lua and Python and I think it can be quite nice.
>> > Especially for making PEG combinator stuff:
>> >
>> > term = Any(1) // any 1 character
>> > whitespace = Range(CharSet(' \t'), 1, Infinity) // space or tab,
>> > repeated 1 or more times
>> > indented_term = whitespace + term // will match: '  x'
>> >
>> > result = indented_term.parse('text...')
>> >
>> > Okay this is a bad example.  But when you're building a grammar
>> > description from objects it can be quite fun to make use of operator
>> > overloading for a much cleaner description - somewhat like a
>> > domain-specific language (DSL) within JS.  LPeg in Lua and PyPeg in
>> > Python make this rather pleasant.
>> >
>> > Anyway, I suspect it won't matter what syntactic features Javascript
>> > gains once WebAssembly gets adopted.  We already have the fundamentals
>> > like inheritance in place so that any language can compile to a
>> > WebAssembly AST and run as one would expect.
>> > ___
>> > es-discuss mailing list
>> > es-discuss@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re[2]: Operators overriding

[Coroutines]

On Mon, Dec 28, 2015 at 9:55 AM, Bradley Meck  wrote:
> Who would think not knowing what `a+b` could do as a pitfall? /s
>
> I am not a big fan of overloading though, since it presents more mental
> complexity as they map to functions without looking like function calls.

>From the Wikipedia page on ecmascript it seemed like operator
overloading was already a for-sure planned feature of ES7, just not
fleshed out in a spec.  I personally do love operator overloading - I
am used to it from Lua and Python and I think it can be quite nice.
Especially for making PEG combinator stuff:

term = Any(1) // any 1 character
whitespace = Range(CharSet(' \t'), 1, Infinity) // space or tab,
repeated 1 or more times
indented_term = whitespace + term // will match: '  x'

result = indented_term.parse('text...')

Okay this is a bad example.  But when you're building a grammar
description from objects it can be quite fun to make use of operator
overloading for a much cleaner description - somewhat like a
domain-specific language (DSL) within JS.  LPeg in Lua and PyPeg in
Python make this rather pleasant.

Anyway, I suspect it won't matter what syntactic features Javascript
gains once WebAssembly gets adopted.  We already have the fundamentals
like inheritance in place so that any language can compile to a
WebAssembly AST and run as one would expect.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re[2]: Operators overriding

[/#!/JoePea]

I'm kind of on the fence about it. `let result =
matrix1.multiply(matrix2)` works for graphics, but `var result =
matrix1 * matrix2` could be nice.

Now that I think about it, I think I'll fall over onto the +1 side of
the fence, because one of the things I love about JavaScript is how
flexible it is as a language, and this adds to that flexibility that
developers have in choosing how they write code.

On Mon, Dec 28, 2015 at 10:26 AM, Coroutines  wrote:
> On Mon, Dec 28, 2015 at 9:55 AM, Bradley Meck  wrote:
>> Who would think not knowing what `a+b` could do as a pitfall? /s
>>
>> I am not a big fan of overloading though, since it presents more mental
>> complexity as they map to functions without looking like function calls.
>
> From the Wikipedia page on ecmascript it seemed like operator
> overloading was already a for-sure planned feature of ES7, just not
> fleshed out in a spec.  I personally do love operator overloading - I
> am used to it from Lua and Python and I think it can be quite nice.
> Especially for making PEG combinator stuff:
>
> term = Any(1) // any 1 character
> whitespace = Range(CharSet(' \t'), 1, Infinity) // space or tab,
> repeated 1 or more times
> indented_term = whitespace + term // will match: '  x'
>
> result = indented_term.parse('text...')
>
> Okay this is a bad example.  But when you're building a grammar
> description from objects it can be quite fun to make use of operator
> overloading for a much cleaner description - somewhat like a
> domain-specific language (DSL) within JS.  LPeg in Lua and PyPeg in
> Python make this rather pleasant.
>
> Anyway, I suspect it won't matter what syntactic features Javascript
> gains once WebAssembly gets adopted.  We already have the fundamentals
> like inheritance in place so that any language can compile to a
> WebAssembly AST and run as one would expect.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re[2]: Operators overriding

[Sander Deryckere]

There are so many places where overloading would be useful., even between
different data types:

* adding vectors
* multiplying vectors with matrices
* multiplying vectors with numbers
* multiplying or adding matrices
* adding (or subtracting) date objects (to get a time difference)

Certainly in the case of working with vectors, you often need long
calculations with intermediate results. In those cases, it's also often
convenient to use short names (as the names are very local). So while
myFirstMatrix.multiply(mySecondMatrix) is acceptable, m1.multiply(m2) isn't
so acceptable. it distracts your attention too much to the name "multiply"
instead of letting you see the math behind it.

I like JavaScript as a versatile language. It really gives the programmer
the responsibility to write good code. Of course you can write bad code
with operation overloading, but you can also write bad code now.

Regards,
Sander


2015-12-28 19:45 GMT+01:00 /#!/JoePea :

> I'm kind of on the fence about it. `let result =
> matrix1.multiply(matrix2)` works for graphics, but `var result =
> matrix1 * matrix2` could be nice.
>
> Now that I think about it, I think I'll fall over onto the +1 side of
> the fence, because one of the things I love about JavaScript is how
> flexible it is as a language, and this adds to that flexibility that
> developers have in choosing how they write code.
>
> On Mon, Dec 28, 2015 at 10:26 AM, Coroutines  wrote:
> > On Mon, Dec 28, 2015 at 9:55 AM, Bradley Meck 
> wrote:
> >> Who would think not knowing what `a+b` could do as a pitfall? /s
> >>
> >> I am not a big fan of overloading though, since it presents more mental
> >> complexity as they map to functions without looking like function calls.
> >
> > From the Wikipedia page on ecmascript it seemed like operator
> > overloading was already a for-sure planned feature of ES7, just not
> > fleshed out in a spec.  I personally do love operator overloading - I
> > am used to it from Lua and Python and I think it can be quite nice.
> > Especially for making PEG combinator stuff:
> >
> > term = Any(1) // any 1 character
> > whitespace = Range(CharSet(' \t'), 1, Infinity) // space or tab,
> > repeated 1 or more times
> > indented_term = whitespace + term // will match: '  x'
> >
> > result = indented_term.parse('text...')
> >
> > Okay this is a bad example.  But when you're building a grammar
> > description from objects it can be quite fun to make use of operator
> > overloading for a much cleaner description - somewhat like a
> > domain-specific language (DSL) within JS.  LPeg in Lua and PyPeg in
> > Python make this rather pleasant.
> >
> > Anyway, I suspect it won't matter what syntactic features Javascript
> > gains once WebAssembly gets adopted.  We already have the fundamentals
> > like inheritance in place so that any language can compile to a
> > WebAssembly AST and run as one would expect.
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re[2]: Operators overriding

[Bradley Meck]

type coercion of `.valueOf` of `.toString` variety is guaranteed to return
a specific type (based upon hints). There is a small surface area to what
the total possible outcomes of using `+` and having coercion could return.
Not true in a operator overloading world.

I am not saying that confusions are not present, just that we should not
add more. Having one wart does not merit having more.

On Mon, Dec 28, 2015 at 12:19 PM, Alexander Jones <a...@weej.com> wrote:

> Regarding not knowing what `a + b` does: you *already* don't know because
> it invokes `.valueOf`. If you already know the operands are typeof
> "number", you're good to optimise just as much as with operator overloading.
>
> Aside from that, we're back into arguments about the clarity benefits of
>
>  * paren-free function invocation
>  * non-member, postfix function call syntax, aka `::`
>
> And finally, any discussion about the perceived "mental tax" of operators
> would be incomplete without a reference to the definition of the `+`
> operator in ECMAScript 2016[1]. Ever tried explaining to beginners what the
> result of `[] + {}` is, while keeping a straight face?
>
> 1.
> http://www.ecma-international.org/ecma-262/6.0/#sec-addition-operator-plus
>
> On 28 December 2015 at 17:59, /#!/JoePea <j...@trusktr.io> wrote:
>
>> I'm in favor of no overloading for the reason of the mental tax.
>> People could write a program where everything is a mathematical
>> operation (in looks, not necessarily functionality), which could
>> encourage harder-to-read code. I think `this.plus(that)` is fine for
>> objects. With a proper auto-completing editor, this really isn't that
>> difficult. Plus, there's Sweet.js if you really want it.
>>
>> On Mon, Dec 28, 2015 at 9:55 AM, Bradley Meck <bradley.m...@gmail.com>
>> wrote:
>> > Who would think not knowing what `a+b` could do as a pitfall? /s
>> >
>> > I am not a big fan of overloading though, since it presents more mental
>> > complexity as they map to functions without looking like function calls.
>> >
>> > On Mon, Dec 28, 2015 at 11:52 AM, Alexander Jones <a...@weej.com>
>> wrote:
>> >>
>> >> Who would have thought using completely un-semantic idioms such as |0
>> and
>> >> !! would lead to issues down the line? /s
>> >>
>> >> On 28 December 2015 at 14:50, Nicolas B. Pierron
>> >> <nicolas.b.pier...@mozilla.com> wrote:
>> >>>
>> >>> This is right, currently code such as "asm js" rely on "a | 0" and
>> >>> "+a" to force a type interpretation. Having an override means that we
>> >>> would have to guard explicitly against overridden the operator before
>> >>> entering these sections of code.
>> >>> This will increase the cost of cold calls.  If this is a frequent
>> >>> path, then we would have to infer the type as long as possible to
>> >>> remove such guards.
>> >>>
>> >>> Currently, proxies have more important issues in SpiderMonkey, as they
>> >>> allow to instrument the lookup of properties (which is still in C++)
>> >>> in a side-effectful way.
>> >>>
>> >>> On Sun, Dec 27, 2015 at 9:42 PM, Frankie Bagnardi <
>> f.bagna...@gmail.com>
>> >>> wrote:
>> >>> > Generally letting proxies do more things is a good thing, but what
>> >>> > would be
>> >>> > the cost in optimizing JITs? It seems like e.g. making `a + b` or
>> `a |
>> >>> > 0`
>> >>> > more flexible would also make them slower.  Is this incorrect?
>> >>> >
>> >>> > On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH <kola...@mail.ru> wrote:
>> >>> >>
>> >>> >> I dislike this proposal.
>> >>> >> 1 It is not very good to limit overrideable operators to value
>> >>> >> classes.
>> >>> >> 2 It is not very good to have a lot of custom operators, it will
>> break
>> >>> >> code readability and will allow more efficient obfuscration.
>> >>> >> 3 I think that most of binary non-assigning operators must return a
>> >>> >> new
>> >>> >> object and thats' why they should be not object methods, but the
>> >>> >> methods
>> >>> >> taking 2 (or more if chained!) objects and return the result
>> usually
>> >>> >> of same

Re: Re[2]: Operators overriding

[Frankie Bagnardi]

Generally letting proxies do more things is a good thing, but what would be
the cost in optimizing JITs? It seems like e.g. making `a + b` or `a | 0`
more flexible would also make them slower.  Is this incorrect?

On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH <kola...@mail.ru> wrote:

> I dislike this proposal.
> 1 It is not very good to limit overrideable operators to value classes.
> 2 It is not very good to have a lot of custom operators, it will break
> code readability and will allow more efficient obfuscration.
> 3 I think that most of binary non-assigning operators must return a new
> object and thats' why they should be not object methods, but the methods
> taking 2 (or more if chained!) objects and return the result usually of
> same type.
> вторник, 22 декабря 2015г., 21:45 +03:00 от Sander Deryckere <
> sander...@gmail.com>:
>
>
> IMO, operator overloading is important and different enough to warrant a
> separate syntax.
>
> But the difficulty isn't in defining the operator, but in the ambiguous
> cases. Like what to do when there are 2 different types, how to make sure
> certain relations will stay correct, ...
>
> There's a nice presentation from Brendan Eich here:
> http://www.slideshare.net/BrendanEich/value-objects2
>
> Regards,
> Sander
>
> 2015-12-18 21:24 GMT+01:00 KOLANICH <kola...@mail.ru
> <https://e.mail.ru/compose/?mailto=mailto%3akola...@mail.ru>>:
>
> Hello. What do you think about overriding operators using proxies?
>
> For example
> function A(r=""){
> this.rep=r;
> return new Proxy(this,{operators:{"+":function(a,b){return new
> A(a.rep+"+"+b.rep);}}});
> }
> let a=new A("a"), b=new A("b");
> let c=a+b;
> console.log(c.rep);//a+b
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> <https://e.mail.ru/compose/?mailto=mailto%3aes%2ddisc...@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re[2]: Operators overriding

[KOLANICH]

I dislike this proposal.
1 It is not very good to limit overrideable operators to value classes.
2 It is not very good to have a lot of custom operators, it will break code 
readability and will allow more efficient obfuscration.
3 I think that most of binary non-assigning operators must return a new object 
and thats' why they should be not object methods, but the methods taking 2 (or 
more if chained!) objects and return the result usually of same type.
вторник, 22 декабря 2015г., 21:45 +03:00 от Sander Deryckere < 
sander...@gmail.com> :

>IMO, operator overloading is important and different enough to warrant a 
>separate syntax.
>
>But the difficulty isn't in defining the operator, but in the ambiguous cases. 
>Like what to do when there are 2 different types, how to make sure certain 
>relations will stay correct, ...
>
>There's a nice presentation from Brendan Eich here:  
>http://www.slideshare.net/BrendanEich/value-objects2
>
>Regards,
>Sander
>
>2015-12-18 21:24 GMT+01:00 KOLANICH  < kola...@mail.ru > :
>>Hello. What do you think about overriding operators using proxies?
>>For example
>>function A(r=""){
>>this.rep=r;
>>return new Proxy(this,{operators:{"+":function(a,b){return new 
>>A(a.rep+"+"+b.rep);}}});
>>}
>>let a=new A("a"), b=new A("b");
>>let c=a+b;
>>console.log(c.rep);//a+b
>>
>>___
>>es-discuss mailing list
>>es-discuss@mozilla.org
>>https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Operators overriding

[Sander Deryckere]

IMO, operator overloading is important and different enough to warrant a
separate syntax.

But the difficulty isn't in defining the operator, but in the ambiguous
cases. Like what to do when there are 2 different types, how to make sure
certain relations will stay correct, ...

There's a nice presentation from Brendan Eich here:
http://www.slideshare.net/BrendanEich/value-objects2

Regards,
Sander

2015-12-18 21:24 GMT+01:00 KOLANICH <kola...@mail.ru>:

> Hello. What do you think about overriding operators using proxies?
>
> For example
> function A(r=""){
> this.rep=r;
> return new Proxy(this,{operators:{"+":function(a,b){return new
> A(a.rep+"+"+b.rep);}}});
> }
> let a=new A("a"), b=new A("b");
> let c=a+b;
> console.log(c.rep);//a+b
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Operators overriding

[KOLANICH]

Hello. What do you think about overriding operators using proxies?
For example
function A(r=""){
this.rep=r;
return new Proxy(this,{operators:{"+":function(a,b){return new 
A(a.rep+"+"+b.rep);}}});
}
let a=new A("a"), b=new A("b");
let c=a+b;
console.log(c.rep);//a+b
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: UInt8ClampedArray Bitwise operators?

[Isiah Meadows]

I can see why, since nearly everyone depends on that coupling. Minifiers
depend on it. Mixin utilities depend on it. Breaking the Web would be an
understatement.

On Wed, Aug 12, 2015, 14:36 Brendan Eich bren...@mozilla.org wrote:

 Caitlin Potter wrote:
  ES2015 already has element accessor overloading with proxies, right?
It's everything else that's missing.
 
  Proxies enforce invariants, which is problematic for this use case
 because it’s A) expensive, and B) also restricts you from “lying” about the
 actual properties which exist on the element.
 
  I recall from an old presentation on Value Types that overloading `[]`
 was off limits because those invariants needed to keep working.

 No operator proposal has included property access, not so much for
 reasons you give (which are good ones) but for separation of concerns.
 Allen did propose:

 http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation

 This was controversial in the committee when last considered. Just sayin'!

 /be
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: UInt8ClampedArray Bitwise operators?

[Isiah Meadows]

Oh. Pardon my ignorance. Misunderstood the idea.

On Wed, Aug 12, 2015, 23:19 Allen Wirfs-Brock al...@wirfs-brock.com wrote:

 On Aug 12, 2015, at 7:30 PM, Isiah Meadows wrote:

 I can see why, since nearly everyone depends on that coupling. Minifiers
 depend on it. Mixin utilities depend on it. Breaking the Web would be an
 understatement.


 Not so clear.  The proposed default default for an indexed access would be
 exactly the same as for legacy property access.  It is pretty much just
 providing a signal to the meta level that opens the possibility of newly
 defined object treating [ ] member accesses differently from .  member
 accesses.

 Allen


 On Wed, Aug 12, 2015, 14:36 Brendan Eich bren...@mozilla.org wrote:

 Caitlin Potter wrote:
  ES2015 already has element accessor overloading with proxies, right?
It's everything else that's missing.
 
  Proxies enforce invariants, which is problematic for this use case
 because it’s A) expensive, and B) also restricts you from “lying” about the
 actual properties which exist on the element.
 
  I recall from an old presentation on Value Types that overloading `[]`
 was off limits because those invariants needed to keep working.

 No operator proposal has included property access, not so much for
 reasons you give (which are good ones) but for separation of concerns.
 Allen did propose:

 http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation

 This was controversial in the committee when last considered. Just sayin'!

 /be
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: UInt8ClampedArray Bitwise operators?

[Caitlin Potter]

Oh, forgot to add a bit to those snippets to divide the bytes_per_element into 
bits, but yeah

 On Aug 11, 2015, at 2:55 PM, Michael McGlothlin mike.mcgloth...@gmail.com 
 wrote:
 
 SIMD types appear almost as limited in size as using numbers. Often I need to 
 manipulate thousands or millions of bits efficiently so fumbling around with 
 numbers is messy.
 
 I've looked at several implementations on npm but none seemed very mature or 
 standard.
 
 I guess it's philosophical as much as anything. In my mind the heart of 
 programming is bits and bytes so I find it odd that most programming 
 languages treat bits and bytes as strange uncles. In my mind all other data 
 types are derived from bits and bytes so it should be possible to easily 
 derive my own types this way or see the bits behind the types that are 
 built-in.
 
 In this case I'm implementing a bit index (which is something I use a lot) 
 for quickly finding relationships in complex data. Often I want to mess with 
 bits for working with specifics of file formats and network protocols. When 
 working with large numbers it's nice to not worry about limits. And I work 
 directly with bits when doing electronics.
 
 I'm not surprised that it's not supported but it seemed to go with the idea 
 of a byte array so I was hopeful. And it seems more generally useful than 
 things like SIMD types.
 
 Thanks,
 Michael McGlothlin
 Sent from my iPhone
 
 On Aug 10, 2015, at 7:36 PM, Daniel Ehrenberg little...@chromium.org wrote:
 
 SIMD types have bitwise operators, but SIMD.js exposes just fixed-size
 vectors that are optimized to what hardware can optimize certain
 operations for. A future extension (the long SIMD API) may operate
 on whole arrays. I wouldn't recommend using SIMD.js unless you really
 feel like you're taking advantage of the better performance, and the
 particular vector size works for your requirements.
 
 The point of SIMD is to expose higher-performance hardware features to
 users. You may want to use this for implementing bitwise operations in
 user code. However, if you don't need that, it may be enough for you
 to use existing operators  | ^ ~ etc, in a loop. A search on npm
 yields tons of bitarray libraries which probably do this already,
 though I haven't assessed how good they are.
 
 If you were getting at operator overloading in particular, operators
 are already well-defined on things like Uint8Array: Roughly speaking,
 they will call .valueOf() and, if that results in a Number they will
 do the operation on the underlying Number. There's no built-in valueOf
 method for that object, but you can always monkeypatch one in. Here's
 an example session in the V8 command-line shell:
 
 d8 Uint8ClampedArray.prototype.valueOf = function() { return 1 }
 function () { return 1 }
 d8 new Uint8ClampedArray([1, 2])  3
 8
 
 The downside of doing anything beyond existing npm packages and
 changing the language is that it increases complexity. What is the
 upside you have in mind to building it into the language?
 
 Have fun!
 Dan
 
 On Mon, Aug 10, 2015 at 4:35 PM, Isiah Meadows isiahmead...@gmail.com 
 wrote:
 Do SIMD types solve your problem?
 
 https://github.com/tc39/ecmascript_simd
 
 
 On Mon, Aug 10, 2015, 10:58 Michael McGlothlin mike.mcgloth...@gmail.com
 wrote:
 
 Would there be a downside to extending Bitwise operators to work with
 typed arrays such as UInt8ClampedArray? To me it seems natural to want to
 perform bit operations on these. Or is there a better way to make a BitSet
 that I'm missing?
 
 
 Thanks,
 Michael McGlothlin
 Sent from my iPhone
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss
 
 
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss
 
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: UInt8ClampedArray Bitwise operators?

[Caitlin Potter]

Well, you could just use typed arrays for this, and add a helper function which 
retrieves the bit at a specific index. Like, something like this:

```
function bitset_get(ta, i) {
  var e = (i / ta.BYTES_PER_ELEMENT) | 0;
  i = i %  ta.BYTES_PER_ELEMENT;
  return (ta[e]  i)  1;
}
```

You could do similar stuff for manipulation, like

```
function bitset_flip(ta, i) {
  var e = (i / ta.BYTES_PER_ELEMENT) | 0;
  i = i %  ta.BYTES_PER_ELEMENT;
  ta[e] ^= (1  i);
  return (ta[e]  i)  1;
}
```

If your typed array is of a smallish type, like unsigned 16 bits, you should be 
able to predictably use SMI integrals when manipulating them, which might 
prevent some accidental floating point bugs.

And you could even make these robust by ensuring they match the bitwise and 
bytewise endianness of the underlying architecture, with some simple tests.

Operator overloading or value types might make it look a lot prettier some day 
(though iirc element assessor overloading was off limits), but you could get 
pretty far by baking it into a compile-to-js language.

If people were using stuff like that commonly, it might end up in the standard 
lib some day.

Apologies for any typos or nonsense grammar, Swype is bad

 On Aug 11, 2015, at 2:55 PM, Michael McGlothlin mike.mcgloth...@gmail.com 
 wrote:
 
 SIMD types appear almost as limited in size as using numbers. Often I need to 
 manipulate thousands or millions of bits efficiently so fumbling around with 
 numbers is messy.
 
 I've looked at several implementations on npm but none seemed very mature or 
 standard.
 
 I guess it's philosophical as much as anything. In my mind the heart of 
 programming is bits and bytes so I find it odd that most programming 
 languages treat bits and bytes as strange uncles. In my mind all other data 
 types are derived from bits and bytes so it should be possible to easily 
 derive my own types this way or see the bits behind the types that are 
 built-in.
 
 In this case I'm implementing a bit index (which is something I use a lot) 
 for quickly finding relationships in complex data. Often I want to mess with 
 bits for working with specifics of file formats and network protocols. When 
 working with large numbers it's nice to not worry about limits. And I work 
 directly with bits when doing electronics.
 
 I'm not surprised that it's not supported but it seemed to go with the idea 
 of a byte array so I was hopeful. And it seems more generally useful than 
 things like SIMD types.
 
 Thanks,
 Michael McGlothlin
 Sent from my iPhone
 
 On Aug 10, 2015, at 7:36 PM, Daniel Ehrenberg little...@chromium.org wrote:
 
 SIMD types have bitwise operators, but SIMD.js exposes just fixed-size
 vectors that are optimized to what hardware can optimize certain
 operations for. A future extension (the long SIMD API) may operate
 on whole arrays. I wouldn't recommend using SIMD.js unless you really
 feel like you're taking advantage of the better performance, and the
 particular vector size works for your requirements.
 
 The point of SIMD is to expose higher-performance hardware features to
 users. You may want to use this for implementing bitwise operations in
 user code. However, if you don't need that, it may be enough for you
 to use existing operators  | ^ ~ etc, in a loop. A search on npm
 yields tons of bitarray libraries which probably do this already,
 though I haven't assessed how good they are.
 
 If you were getting at operator overloading in particular, operators
 are already well-defined on things like Uint8Array: Roughly speaking,
 they will call .valueOf() and, if that results in a Number they will
 do the operation on the underlying Number. There's no built-in valueOf
 method for that object, but you can always monkeypatch one in. Here's
 an example session in the V8 command-line shell:
 
 d8 Uint8ClampedArray.prototype.valueOf = function() { return 1 }
 function () { return 1 }
 d8 new Uint8ClampedArray([1, 2])  3
 8
 
 The downside of doing anything beyond existing npm packages and
 changing the language is that it increases complexity. What is the
 upside you have in mind to building it into the language?
 
 Have fun!
 Dan
 
 On Mon, Aug 10, 2015 at 4:35 PM, Isiah Meadows isiahmead...@gmail.com 
 wrote:
 Do SIMD types solve your problem?
 
 https://github.com/tc39/ecmascript_simd
 
 
 On Mon, Aug 10, 2015, 10:58 Michael McGlothlin mike.mcgloth...@gmail.com
 wrote:
 
 Would there be a downside to extending Bitwise operators to work with
 typed arrays such as UInt8ClampedArray? To me it seems natural to want to
 perform bit operations on these. Or is there a better way to make a BitSet
 that I'm missing?
 
 
 Thanks,
 Michael McGlothlin
 Sent from my iPhone
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss
 
 
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org

Re: UInt8ClampedArray Bitwise operators?

[Caitlin Potter]

 ES2015 already has element accessor overloading with proxies, right?
 It's everything else that's missing.

Proxies enforce invariants, which is problematic for this use case because it’s 
A) expensive, and B) also restricts you from “lying” about the actual 
properties which exist on the element.

I recall from an old presentation on Value Types that overloading `[]` was off 
limits because those invariants needed to keep working.


 On Aug 12, 2015, at 1:44 PM, Daniel Ehrenberg dehrenb...@chromium.org wrote:
 
 On Wed, Aug 12, 2015 at 4:50 AM, Caitlin Potter caitpotte...@gmail.com 
 wrote:
 Operator overloading or value types might make it look a lot prettier some 
 day (though iirc element assessor overloading was off limits), but you could 
 get pretty far by baking it into a compile-to-js language.
 
 ES2015 already has element accessor overloading with proxies, right?
 It's everything else that's missing.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: UInt8ClampedArray Bitwise operators?

[Daniel Ehrenberg]

On Wed, Aug 12, 2015 at 4:50 AM, Caitlin Potter caitpotte...@gmail.com wrote:
 Operator overloading or value types might make it look a lot prettier some 
 day (though iirc element assessor overloading was off limits), but you could 
 get pretty far by baking it into a compile-to-js language.

ES2015 already has element accessor overloading with proxies, right?
It's everything else that's missing.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: UInt8ClampedArray Bitwise operators?

[Jordan Harband]

Also `instanceof` overloading via `Symbol.hasInstance`

On Wed, Aug 12, 2015 at 10:44 AM, Daniel Ehrenberg dehrenb...@chromium.org
wrote:

 On Wed, Aug 12, 2015 at 4:50 AM, Caitlin Potter caitpotte...@gmail.com
 wrote:
  Operator overloading or value types might make it look a lot prettier
 some day (though iirc element assessor overloading was off limits), but you
 could get pretty far by baking it into a compile-to-js language.

 ES2015 already has element accessor overloading with proxies, right?
 It's everything else that's missing.
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss