Nov 18 notes

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Nov 22 17:39:34 PST 2010


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



More information about the es-discuss mailing list