-----Original Message-----
From: David Herman
Sent: Monday, November 22, 2010 3:55 PM
To: Allen Wirfs-Brock
Cc: Brendan Eich ; Oliver Hunt ; es-discuss
Subject: Re: Nov 18 notes
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.
AWB: Perhaps I should have been a bit more general in 1d and said something
like: "respect precedent, except when it gets in the way". Precedent can
mislead users as easily as it can help help them. One think I suspect that
we have all observed (and probably experience) is the experienced
programmers who starts trying to write JavaScript programmers using invalid
assumptions based upon their experience with other 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.
AWB: Thanks, I like that. Trying to articulate some principles was the
main point. I felt the thread was feeling like it getting hung up on
unstated and/or unshared prinicples.
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."
AWB: This was mainly a first cut trying to look at the problem from a
slightly different angle but starting by only using the currently available
set of reserved words. Other syntactic issues like usage of parenthesis
could tweaked and in the end wouldn't seem particularly inconsistent with
the syntax conventions for C-like languages. I agree that we have
generally called this semantics iteration rather than enumeration, but I was
working from out available set of reserved words and "enum" seems like the
closest fit. I suspect that the majority of Javascript programmers couldn't
really articulate the difference between enumeration and iteration (over).
They will use whatever meaning we feed them via the language design. Of
course, we should be consistent in our terminology and if we went this route
we might want to adjust other uses of these terms. Also, it there are JS
1.8 precedent issues--I'm just not sure whether that usage is broad enough
to matter that much.
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.
AWB: I worry that it is hard for people to learn when the same name is
applied to different concepts. We already have two forms of the "for"
statement that people have to learn. Further complicating it feels like it
would be a pedagogical nightmare.
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.
I haven't really studied the specific Proxy traps in detail. However, if we
had a more generate iterate trap(s) that semantically subsumes the enumerate
trap when used with appropriate desugaring, why would we need an additional
enumerate trap. I think I will have some more to say about this in response
to Brendan.
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
