The only thing I find off the mark is the typography of <|.
In light of this, and of the anti-grawlix reaction among
many people, could we revisit an infix operator used in
restricted productions with [no LineTerminator here] on
the left of the operator contextual keyword?
Am I the only one who flinches when someone mentions
adding another [no LineTerminator here]?
Apart from adding to ASI fun (the less of which, the better),
these suggestions are phrases, to be written in a certain
layout. That is different from infix operators, and even infix
operators are not as flexible as I'd like in JS (can't easily
pass them as parameters, for a start).
To balance the 'anti-grawlix' slogan, perhaps we should
try to coin a counter-meme. How about 'cobol.js' for
English-like infix operator phrases that aren't really infix
operators, and aren't really English.
As observed by Wadler, syntax details draw the most replies
in language design discussions
http://lambda-the-ultimate.org/node/4287
So, much as I'd like to, I'll not express my preferences on
the syntax here. Instead, I'd like to call attention to some
of the semantic, pragmatic, and organizational aspects
that are still troubling me:
- there are several parts of code that would be awkward
to abstract over (restriction to object literals, infix operators),
or make it difficult to use the new features in expression-
oriented styles (in-place modification);
these surface issues are pointing to deeper language design
issues that have not been tackled yet (object cloning/copying,
user-defined infix operators and conversion between infix
operators and prefix functions)
- infix operators fall into that hole of macros-later, value
proxies later, no user-defined infix ops; it is interesting
how much time is spent on specific infix operator
questions here, given that some committee members
were opposed to a general solution
- the only argument against generalizing from object
literals and avoiding in-place update was that cloning/
copying would be non-trivial to get right;
but that non-triviality seems to me a very good reason
why the language standard should have something to
say about the topic; it comes up in several contexts;
if you don't want to commit to deep or shallow or
whatever forms of cloning/copying yet, how about
defining the several possible forms, and providing
operators/functions for them?
Btw: several of my messages have not yet appeared
on es-discuss, and es-discuss-owner is unresponsive.
Claus
http://clausreinke.github.com/
http://clausreinke.github.com/js-tools/
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
