On Nov 22, 2010, at 3:17 PM, Allen Wirfs-Brock wrote:
> Rather than adding additional confusion by trying to comment on snippets from
> this thread, I think I'll just state my current opinions on the subject and
> the principles that they are based upon:
>
> 1a) New semantics should use new syntax in a manner that clearly avoids
> confusion with existing syntax.
> 1b) Syntax should generally be suggestive of a reasonable interpretation of
> the semantic
> 1c) Harmony is not being designed using the "no new syntax" rule
> 1d) There is nothing sacred about "for" as the initial keyword of an
> enumeration statement.
I will echo Dave in saying thanks for spelling out principles. Also that
"sacred" is a bit one-sided -- I do not think your (1a) is sacred either. Are
we "even"? :-|
The forest-for-the-trees meta-point is that if we conservatively add new syntax
when meta-programming existing would have gone over without incident, we've
made the language irrevocably bigger. We can't ever take back the new syntax or
get rid of the old. We will have a long wait switching developers over to the
new, which has ripple effects as Tom's post pointed out.
But no need to beat that drum again, I will stifle.
> From these I conclude that new iteration semantics should be syntactically
> distinct from the current for-in and probably the greater the syntactic
> distance from for-in the better. Following these principles, here is a
> suggestion for a new enumeration statement that makes use of existing
> reserved words:
>
> enum key with keys(x) {
This is a clever homage to "with" :-P.
The parenthesis-free head is unusual and invites Go-like innovation elsewhere:
will Harmony drop mandatory parens around if, while, etc. heads?
Iteration is not numbering or naming, so taking enum for this purpose
promulgates a misnomer *and* precludes us using enum for a categorical sum
declaration of some sort.
> 2) Whenever possible, less general pre-existing syntactic forms should be
> redefined to desugar into new more general forms.
>
> ES1-5 for-in can be defined via desugaring to enum-with, for example:
>
> //desugar: for (var x in foo) {alert(foo[x])}
> var x;
> enum __x with __ES5forinEnumerator(x) {
> x=__x;
> {alert(foo[x])}
> }
This goes against the Proxy design. A proxy shouldn't have to special case
__ES5forinEnumerator to customize for-in as opposed to enum-with, and
customizing for-in should not affect enum-with when up the proto chain as one
of my recent posts showed with a js shell session.
If we must have new syntax to get customized iteration through TC39, we can
spend way too much time coming up with acceptable syntax. But before we dive
into that fun timekilling process, let's be really sure we are not missing the
forest for the trees.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
