Nov 18 notes

David Herman dherman at
Mon Nov 22 15:55:26 PST 2010

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

Nobody said "sacred" -- I'm not genuflecting. :) Seriously, the reason for using "for" is that it's one of the most stable, common, and universally-used keywords for iteration in almost all languages. Introducing a new initial keyword is straying really far from precedent, both in JS and other imperative languages.

But I appreciate your spelled-out premises. I think my main quibble is with 1a as a rule. I might prefer something like:

2a) If existing syntax is given new semantics, it should extend the existing semantics conservatively. Otherwise, the new semantics should get new syntax.

> 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) {
>   alert(key)
> }

This is clever, but it just seems to go off the deep end: the syntax is too inconsistent with JS precedent. Also, "enum" is the wrong keyword -- in JS parlance, this is "iteration" not "enumeration."

I guess I'm still open to new syntaxes, but I also still feel that when you step back and weigh the trade-offs, the cost of all this new syntax is incommensurate with the amount of new semantics, and moreover the traditional for-in syntax is still the sweetest I've seen for custom iteration. I would rather extend the best syntax and leave the legacy special case as a very small wart than have a warty syntax with a supremely orthogonal semantics.

> 2) Whenever possible, less general pre-existing syntactic forms should be redefined to desugar into new more general forms.

I think this is pretty uncontroversial; whatever syntax we decide on, the specific legacy construct can be defined in terms of the more general new construct.

> 3) Proxy traps should be defined based upon the new, more general semantics not legacy less general semantics.
> Define the traps necessary to support enum-with and depend upon the desugaring to take care of legacy for-in.

You don't think for-in should even allow the enumerate trap? This seems to go against the design approach of proxies; it's not just for introducing new meta-programmable constructs, but also for meta-programming existing facilities.

> 4) Provide builtin-library alternatives for new statements that can be used without down-rev syntax errors:

This seems like a good idea.


More information about the es-discuss mailing list