Proposed ES4 draft 1
2008/5/17 Lars Hansen <lhansen at adobe.com>:
Enclosed is a quite incomplete first draft of the specification for the Proposed ECMAScript 4th Edition. This draft is comprised of a short introduction, the surface grammar, and a description of the core semantics -- values, storage, types, names, scopes, and name resolution. More will follow as it is ready, probably on a (more or less) bimonthly schedule. See the introduction for a general discussion.
In core-language.pdf, section "1.2 Null", the note reads "NOTE While the null and undefined values have similar meanings, they have different conventions of use. The null value is intended to indicate a missing object value, while the undefined value is intended to indicate a missing property on an existing object value. These indeded uses are conventions, and are not enforced by the language semantics."
Besides the obvious spelling error, I think your terminology of "missing object value" and "indicating missing property on an existing object" are actually more confusing than helping. I would characterise null as being the "invalid object value"; i.e. "the object that is not an object", in analogy with NaN being "a number that is not a number". (Or s/the (object|number)/the value/ if you prefer that, since the spec specifically mentions null not being an object.) The value undefined on the other hand has several distinct meanings: It either represents a storage slot (variable/argument/object property) that has not been assigned a value, it represents a storage slot not existing at all, or it represents a storage slot explicitly being set to undefined by the programmer. Three entirely different things. I like to explain that as undefined being the "value that is not a value" in analogy to how I explain null and NaN. Not saying I think the spec should say just those things in particular, just that I think your characterisation of them is a bit dissonant with their nature, especially undefined being much broader in meaning than your definition of it.
In core-language.pdf, "1.3.1 Property Binding Map", a paragraph reads: "A property binding map stores the order in which properties are added to the map. A property's position in this order is unchanged when the property is replaced. This order is used by property enumeration (see the chapter on Statements)."
I just wish you make clear one detail here: Does removing and adding a property with the same name change its enumeration order, or is that equivalent to a replacement? I think it probably should remove it from the enumeration order and insert it at the end. Also, knowing a bit about Opera's planned behaviour on this for Futhark , I'd like the correct behaviour for enumeration after a delete well defined.
In core-language.pdf, "1.4.5 String Values", you allow both ES3 compatible 16-bit UCS-2 code units and 32-bit Unicode code points (and, I would assume, 21-bit code units which would behave exactly as if they were UTF-32 code units). If an implementation is UTF-8 under the hood but leaves the programmer-visible indexed access per either one of those models (with notably worse algorithmical complexity for random access but not for serial access), is that okay per the spec?
In core-language.pdf, "2.1 Catch-All Methods", the default behaviour of accessing the value from a dynamic property in the object's property map is mentioned. Is there a way for non-default catch-alls to do this, too? (Maybe they only want to treat a special subset of property names differently, not all names...)
In core-language.pdf, "2.3 Reading a property value" the last fixme reads: "FIXME We need to specify whether the bound method is cached or not, ie, whether, given that o.m is a method, (o.m === o.m)."
Whether o.m is a method or not shouldn't change anything, should it? As long as it's just named and not called it's the same object. If there's a setter or getter for that particular name or a catch-all, now, that's where this issue arises.
-----Original Message----- From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of liorean Sent: 17. mai 2008 03:07 To: es4-discuss at mozilla.org Subject: Re: Proposed ES4 draft 1
In core-language.pdf, "1.3.1 Property Binding Map", a paragraph reads: "A property binding map stores the order in which properties are added to the map. A property's position in this order is unchanged when the property is replaced. This order is used by property enumeration (see the chapter on Statements)."
I just wish you make clear one detail here: Does removing and adding a property with the same name change its enumeration order, or is that equivalent to a replacement? I think it probably should remove it from the enumeration order and insert it at the end.
I agree, and I think the spec needs to be clear on this.
In core-language.pdf, "1.4.5 String Values", you allow both ES3 compatible 16-bit UCS-2 code units and 32-bit Unicode code points (and, I would assume, 21-bit code units which would behave exactly as if they were UTF-32 code units). If an implementation is UTF-8 under the hood but leaves the programmer-visible indexed access per either one of those models (with notably worse algorithmical complexity for random access but not for serial access), is that okay per the spec?
If it's under the hood it's out of the spec's jurisdiction, but it's possible the spec could be clearer about that. We'll see.
In core-language.pdf, "2.1 Catch-All Methods", the default behaviour of accessing the value from a dynamic property in the object's property map is mentioned. Is there a way for non-default catch-alls to do this, too? (Maybe they only want to treat a special subset of property names differently, not all names...)
There is not.
In core-language.pdf, "2.3 Reading a property value" the last fixme reads: "FIXME We need to specify whether the bound method is cached or not, ie, whether, given that o.m is a method, (o.m === o.m)."
Whether o.m is a method or not shouldn't change anything, should it? As long as it's just named and not called it's the same object. If there's a setter or getter for that particular name or a catch-all, now, that's where this issue arises.
You're assuming the conclusion. The reason this is an interesting question is that good implementations will not allocate function objects for methods until they need to (at that point performing an implicit 'bind' operation too, of course), and the question is whether implementations will be required to cache these objects when they do create them. I think the sane thing to do is to require lazily created objects to be cached; it simplifies the language and the spec -- objects appear to "have" properties that are bound methods -- even if it adds an additional burden to some implementations.
Hello,
Does anyone else hate PDF?
I want to be able to link to, and discuss this. PDF does not allow me to do this. It is difficult to copy paste between pages.
What is wrong with HTML?
Garrett
-----Original Message----- From: Garrett Smith [mailto:dhtmlkitchen at gmail.com] Sent: 31. mai 2008 01:29 To: Lars Hansen Cc: liorean; es4-discuss at mozilla.org Subject: Re: Proposed ES4 draft 1
Hello,
Does anyone else hate PDF?
Would you prefer .doc? ;)
I want to be able to link to, and discuss this. PDF does not allow me to do this. It is difficult to copy paste between pages.
What is wrong with HTML?
Nothing, and in fact the source document for the PDF is an HTML document, as you may have guessed. The main problem with posting that is that most browsers have problems with the CSS it uses, in my experience it only renders and prints correctly in some versions of Opera. The CSS could be broken and I'd appreciate corrections to it, but I suspect it's browsers lagging or getting it wrong. (On the other hand, Opera's printing subsystem raises all monospace fonts by a couple of points so the result is far from pretty. Sigh.)
I'll look into putting the HTML up on ecmascript.org sometime this week. Thanks for bringing it up.
Enclosed is an update to the draft ES4 specs. This includes revisions of the introduction, grammar and core-language specs of draft 1 (16-May) as well as an initial draft of the library spec.
Also included are files that show the differences between draft 1 and draft 2 specs. There have been substantial changes to the text of the core-language spec and so the difference file for that spec is quite noisy. Two changes that contribute significantly to the noise are the renaming of "rib" to "fixture map", and the simplification of the name resolution algorithms (in particular reducing the required number of search passes from two to one).
These specs should be the basis for technical discussions of ES4 on es4-discuss and at the July 23 Oslo meeting.
Enjoy!
Jd
[Patrick, please assign appropriate document numbers and post to the internal TC39 repository. Thanks!]
Since FunctionExpression is PrimaryExpression, so the following statement:
a = function() return b ? c : d;
should be:
a = fe ? c : d fe = function() return b
or
a = fe fe = function() return b ? c : d
And same question for LetExpression.
,
Eric Suen
----- Original Message ---
Enclosed is a quite incomplete first draft of the specification for the Proposed ECMAScript 4th Edition. This draft is comprised of a short introduction, the surface grammar, and a description of the core semantics -- values, storage, types, names, scopes, and name resolution. More will follow as it is ready, probably on a (more or less) bimonthly schedule. See the introduction for a general discussion.