On Thu, Dec 12, 2013 at 2:56 PM, John Barton <johnjbarton at google.com> wrote:

>
>
>
> On Thu, Dec 12, 2013 at 11:53 AM, Mark S. Miller <erights at google.com>wrote:
>>
>> Keep in mind that infix ! is proposed <
>> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency> for use in
>> ES7 to mean "do this operation eventually", e.g.,
>>
>>     p2 = p1 ! foo(a, b);
>>
>
> Please do not do this ;-)
> jjb
>

John, I agree with you on this and have expressed my concern in the past.

I still contend that using "!" to indicate some async characteristic just
reads contradictorily if we consider that "!" as an exclamation is also
used to indicate urgency or immediacy—which are absolutely the opposite of
"async". Of course, it could be argued that using "!" to indicate logical
negation doesn't match its written punctuation meaning either, but that
case is unrelated to both the original meaning and the opposite of the
original meaning (the same arguments are true for its factorial symbol, ML,
Scheme, Ruby and Haskell meanings).

The concurrency strawman[0] proposes "!" as an infix operator, and gives
this as a simple example:

  function add(x, y) { return x + y; }
  const sumP = add ! (3, 5); //sumP resolves in a later turn to 8.

I suppose this isn't so bad, but what about this:

  !isComparable!(a, b);

I don't think it would be hard to explain this, it's just (subjectively)
strange to see. Maybe I'll get over it?

The requisite "[No LineTerminator here]" imposed by "!" (as an infix
operator) creates a retriction that will fail silently:

  function f(n){ return n; }
  f
  (1); // 1
  f
  !(2); // false (but probably expected 2)


Which seems like the kind of issue that the committee has balked at in the
past.


Rick

[0] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131212/543e3c1f/attachment.html>

>>     p2 = p1 ! foo(a, b);
>
> Please do not do this ;-)

John, I agree with you on this and have expressed my concern in the past.

I still contend that using `!` to indicate some async characteristic just
reads contradictorily if we consider that `!` as an exclamation is also
used to indicate urgency or immediacy—which are absolutely the opposite of
"async". Of course, it could be argued that using `!` to indicate logical
negation doesn't match its written punctuation meaning either, but that
case is unrelated to both the original meaning and the opposite of the
original meaning (the same arguments are true for its factorial symbol, ML,
Scheme, Ruby and Haskell meanings).

The [concurrency strawman](http://wiki.ecmascript.org/doku.php?id=strawman:concurrency) proposes `!` as an infix operator, and gives
this as a simple example:

```js
function add(x, y) { return x + y; }
const sumP = add ! (3, 5); //sumP resolves in a later turn to 8.
```

I suppose this isn't so bad, but what about this:

```js
!isComparable!(a, b);
```

I don't think it would be hard to explain this, it's just (subjectively) strange to see. Maybe I'll get over it?

The requisite "[No LineTerminator here]" imposed by "!" (as an infix operator) creates a restriction that will fail silently:

```js
function f(n){ return n; }
f
(1); // 1
f
!(2); // false (but probably expected 2)
```

Which seems like the kind of issue that the committee has balked at in the
past.

>>     p2 = p1 ! foo(a, b);
>
> Please do not do this ;-)
> jjb

John, I agree with you on this and have expressed my concern in the past.

I still contend that using `!` to indicate some async characteristic just
reads contradictorily if we consider that `!` as an exclamation is also
used to indicate urgency or immediacy—which are absolutely the opposite of
"async". Of course, it could be argued that using `!` to indicate logical
negation doesn't match its written punctuation meaning either, but that
case is unrelated to both the original meaning and the opposite of the
original meaning (the same arguments are true for its factorial symbol, ML,
Scheme, Ruby and Haskell meanings).

The [concurrency strawman](http://wiki.ecmascript.org/doku.php?id=strawman:concurrency) proposes `!` as an infix operator, and gives
this as a simple example:

```js
function add(x, y) { return x + y; }
const sumP = add ! (3, 5); //sumP resolves in a later turn to 8.
```

I suppose this isn't so bad, but what about this:

```js
!isComparable!(a, b);
```

I don't think it would be hard to explain this, it's just (subjectively) strange to see. Maybe I'll get over it?

The requisite "[No LineTerminator here]" imposed by "!" (as an infix operator) creates a restriction that will fail silently:

```js
function f(n){ return n; }
f
(1); // 1
f
!(2); // false (but probably expected 2)
```

Which seems like the kind of issue that the committee has balked at in the
past.

>>     p2 = p1 ! foo(a, b);
>
> Please do not do this ;-)
> jjb

John, I agree with you on this and have expressed my concern in the past.

I still contend that using `!` to indicate some async characteristic just
reads contradictorily if we consider that `!` as an exclamation is also
used to indicate urgency or immediacy—which are absolutely the opposite of
"async". Of course, it could be argued that using `!` to indicate logical
negation doesn't match its written punctuation meaning either, but that
case is unrelated to both the original meaning and the opposite of the
original meaning (the same arguments are true for its factorial symbol, ML,
Scheme, Ruby and Haskell meanings).

The [concurrency strawman](http://wiki.ecmascript.org/doku.php?id=strawman:concurrency) proposes `!` as an infix operator, and gives
this as a simple example:

```js
function add(x, y) { return x + y; }
const sumP = add ! (3, 5); //sumP resolves in a later turn to 8.
```

I suppose this isn't so bad, but what about this:

```js
!isComparable!(a, b);
```

I don't think it would be hard to explain this, it's just (subjectively) strange to see. Maybe I'll get over it?

The requisite "[No LineTerminator here]" imposed by "!" (as an infix operator) creates a restriction that will fail silently:

```js
  function f(n){ return n; }
  f
  (1); // 1
  f
  !(2); // false (but probably expected 2)
```

Which seems like the kind of issue that the committee has balked at in the
past.