Nit: 10.2.2.2 refers to type by otherwise unmentioned CamelCaps name

2009-05-19 Thread Jim Blandy
In section 10.2.2.2, algorithm step 2 refers to the declarative 
environment record type by the StUdLyCaPs name 
DeclarativeEnvironmentRecord, which is never defined or used elsewhere.  
Perhaps it should simply be declarative environment record, as used 
elsewhere in the section.


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: yield syntax

2009-05-19 Thread David-Sarah Hopwood
Igor Bukanov wrote:
 2009/5/18 Brendan Eich bren...@mozilla.com:
 On May 18, 2009, at 2:25 AM, Igor Bukanov wrote:
 The plus side of this is that an empty generator can be created with a
 straightforward:

  Generator(function() {})

 and not with a rather unnatural

  (function() { if (false) yield; })()
 No one makes empty generators.
 
 For me the problem with the way the generators are defined is that a
 dead code like that if (0) yield; affects the semantic by mere
 presence of it. Surely, this is not the first feature in ES that has
 that property - if (0) var a; is another example. But if (0)
 yield; sets a new record affecting the nature of the whole function.

A more explicit alternative is to require some kind of decoration on the
function definition, e.g. (just a straw man):

  function generator foo() { ... }

-- 
David-Sarah Hopwood ⚥

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: yield syntax

2009-05-19 Thread Brendan Eich

On May 19, 2009, at 2:00 PM, David-Sarah Hopwood wrote:

*If* it is allowed, then it should be two. It would be very  
surprising if


 foo(a = b, c);

had two arguments (as it does), but the above expression with yield
had one.

But I agree that it may be better not to allow it.


Good; it was a loophole in JS1.7 and up, which I think should be closed.



Agreed; this closes the assignment expression loophole.


This would disallow

 foo(yield x);

which seems unnecessary.


I thought so too, but Python keeps its grammar simple this way, and  
simpler is better, ceteris paribus. JS1.7 allows this but also suffers  
the assignment loophole. Getting rid of the latter but not the former  
is grammar-hacking busy work. I haven't done it in the WebKit/ 
JavaScriptCore/parser/Grammar.y.


/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: yield syntax

2009-05-19 Thread Brendan Eich

On May 19, 2009, at 2:08 PM, David-Sarah Hopwood wrote:

A more explicit alternative is to require some kind of decoration on  
the

function definition, e.g. (just a straw man):

 function generator foo() { ... }


Or just (we discussed this briefly last summer in Oslo):

generator foo() { ... }

In JS1.7, we followed Python, which uses def, same as for defining a  
function, and distinguishes generators by presence of yield (which  
makes value returns illegal). It seems unwise to diverge from Python  
without more evidence of an actual usability problem. We have no such  
evidence from shipping JS1.7 and up in Firefox 2 and up.


/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Techtalk on EcmaScript 5

2009-05-19 Thread Mark S. Miller
Waldemar Horwat, Mike Samuel, and I just gave a Google Techtalk on

Changes to JavaScript, Part 1: EcmaScript 5.

The abstract, bios, and the talk itself are at
http://www.youtube.com/watch?v=Kq4FpMe6cRs.

The slides are at
http://google-caja.googlecode.com/svn/trunk/doc/html/es5-talk/es5-talk.html.

I believe this talk is a good introduction to EcmaScript 5 and its
rationale. Comments appreciated. Enjoy!

-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss