> 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.
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
