Attaching comments.
In general this looks pretty clean. (Some obvious missing parts
excepted.) Of the things that do not look clean I want to single out
three worries specifically: That your strict mode is overreaching, that
too much (any!) emphasis is placed on catering to a non-existent "secure
subset" language, and that strict compatibility has not been maintained
with JS1.6/1.7/1.8 in the methods incorporated from those
specifications. See the comments for details. Also, there are numerous
occasions where the proposed language is incompatible with Proposed ES4,
so we have work to do to reconcile them.
--lars
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pratap Lakshman
(VJ#SDK)
Sent: 12. juni 2008 02:02
To: [EMAIL PROTECTED]
Cc: es4-discuss@mozilla.org
Subject: ES3.1 Draft: 11 June 2008 version available
I have uploaded to the wiki (link
<http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_dra
ft> , see under "Draft Specification") the current draft of the
specification for ES3.1. This is in the form of in-place edits and
markups to the ES3 specification. Revision history is at the end of the
document.
pratap
p1. "... some aspects of the language were defined to operate by
non-strict rules that are quite error prone. For backwards
compatibility, this "non - strict mode" remains the default. But a
scipt can now explicitly declare that it is in "strict mode", which
should make programming more robust for both professionals and
non-professionals."
Editorializing of this sort ("..are quite error prone.") is
inappropriate in a language standard. It would be better simply to
note that the new strict mode catches more errors and that this
benefits large programs in particular.
p2. The inserted reference to the Scheme report appears to be
gratuitous, as Scheme is not mentioned elsewhere in this document
(notably not in the preceding paragraph that mentions Java and Self).
Also, if you're going to mention Scheme then it would be better to
reference the last report (R6RS) or the IEEE standard (based on R4RS).
p2. 4.2#2 The deletion of "is an" to be replaced by "a" makes the
sentence grammatically incorrect.
p2. 4.2#2 (and throughout the document) Merriam-Webster's Collegiate
insists on "writable" and not "writeable". But of course that book
documents US English, and as a non-native speaker of English I'm not
on firm ground here, so I would encourage the input of others.
p2. 4.2#4 The change in wording brings about a change in meaning that
is not obviously desirable, since the original wording allows more
implementation techniques than the new wording.
p3. 4.2.1#1 Inconsistent typography. If you look forward to eg 13.2,
the typesetting for the prototype property is bold monospace; here you
have non-bold monospace with quotation marks. Nobody disputes (I
think) that the ES3 spec could be cleaned up in this regard, but I
feel that the change here is just making matters worse. Whatever you
do, using both monospace and quotes is inappropriate IMO.
p3. 4.2.1#2 This change does not clarify -- the new language is no
less confusing than the old -- and should be reverted. (Furthermore,
the reference is not implicit, but the old spec got that wrong too.)
p4. 4.2.2 Again, editorializing ("error-prone behaviours") is
inappropriate for a language specification.
p5. 4.3.15. No, you can't get rid of wrappers in strict mode (it
would violate the ES3.1 - ES4 subset relationship, for one thing).
p5. 4.3.24. Wording: note that all the preceding paragraphs use
"instance of the built-in X object" not "X constructor". Suggest you
follow that here. Semantics: the notion of "primitive function"
appears nowhere else in the document that I can find and should
probably not be introduced here. Conceivably it could be used to
explain the behavior of Function.prototype.toString on host and native
functions, but as those concepts are already present in ES3 they would
be the better choice.
p8. 5.1.4. Disabling semicolon insertion in strict mode breaks the
ES3.1 - ES4 subset relationship.
p10. 5.2. Though this algorithm notation is an improvement over what
ES3 uses, I question whether it's reasonable to introduce it without
changing all the algorithm descriptions, something I expect you will
not do. IMO you should remove this, and new algorithms should be
described using the same notation as algorithms carried over from ES3.
p13. 7.2, 7.3. LS is U+2028 and PS is U+2029, not the values shown
here. Also, making LS and PS change status from line separator to
whitespace appears to be a gratuitous change. Also, ZWSP is a format
control character in the unicode database, not a whitespace character,
and I'd like to know why this should be singled out if not U+FEFF
(zero width no-break space) should not be incorporated too;
significantly, the latter doubles as the byte order mark (BOM) and ES4
will treat it as a whitespace character between tokens (and as itself
inside string and regular exprssion tokens).
I propose that you not change the status of LS and PS and that you
incorporate U+FEFF in the set of whitespace characters.
p14. 7.5. The inclusion of IdentifierName here appears to have no
effect since Identifier = IdentifierName except ReservedWord. Suggest
you remove this.
p15 7.5.2. Making 'eval' a reserved word breaks the ES3.1 - ES4
subset relationship and breaks the web.
p15 7.5.2. Making 'const' a reserved word appears gratuitous since
ES3.1 does not use it. Please undo this change.
p15 7.6. Removing the comment about allowing identifier characters
from later versions of Unicode breaks the ES3.1 - ES4 subset
relationship.
p22 7.8. Unacceptable change: The requirement to signal regular
expression syntax errors at scanning time breaks existing programs.
(The justification ("since the arguments are the same every tine[sic],
..." appears to have no bearing on that and should be removed in any
case.)
p22 7.9. Requiring semicolons in strict mode breaks the ES3.1 - ES4
subset relationship.
p26 8.6.1. (And throughout the spec) The meaning of "dynamic" in ES4
is something else (it means a non-fixture property). It would
probably reduce confusion if the property name Deletable were used
here, as I though we had agreed previously.
p27 8.6.1. ES4 specifies that the missing sibling of the
getter/setter pair is generated by the system, so [[Getter]] and
[[Setter]] would never be undefined, they would always be functions.
We've done this because we feel it simplifies the language
specification in other places (fewer cases).
p27 8.6.2. Not sure that introducing a notion of "inheritance" here
is useful, since properties are really not copied down to objects;
dynamic properties in prototype objects can become visible and
disappear again without any change to the object that points to the
prototype. Suggest you undo this language.
p27 8.6.2. Again, the attempt to emasculate host objects is likely to
introduce incompatibilities. Suggest you leave this language alone.
p28 8.6.2. Suggest [[IsDynamic]] rather than [[Dynamic]] in order to
avoid confusion with [[Dynamic]] used elsewhere and to conform to the
pattern used elsewhere, in that predicates have a verb in the name.
p28 8.6.2. Remove [[Identity]], it makes no difference.
p29 8.6.2.1.2. The first two steps are duplicated. Also,
disginguishing a Number property here is probably wrong, as for other
objects a["10"] and a[10] mean the same thing always. Also, this
algorithm has more spaghetti than it needs (steps 6-8 should be
inlined into 3). Also, I'm pretty sure this implementation does not
correspond to what's in most browsers, because they usually only query
the string for property names within the string's length, and go to
the underlying object for other names.
p29 8.6.2.1.3. [[SetOwnProperty]] is not actually used anywhere.
p30 8.6.2.2. If I read this correctly you have changed the semantics
of properties by removing the use of [[CanPut]]. (ES4 Draft 1 has the
same bug.) Also, [[Put]] returns a value but the spec in the
preceding table does not specify that, and the value is not used by
any caller of [[Put]] anywhere in the document.
p30 8.6.2.4. This implementation of [[HasProperty]] is not equivalent
to the one in ES3 -- it may end up invoking String.prototype.charAt.
What you want to do in that case is to see if the index is within the
bounds of the string, and if so return true, and if not, query the
property on the object in the normal fashion.
p30 8.6.2.5. This has the same problem as [[HasProperty]], it may end
up invoking charAt. Also, the "else" in clauses 5 and 6 are redundant
(ditto in some of the preceding algorithms).
p31 8.7. I think you should not delete the sentence "No built-in
ECMAScript function defined by this specification returns a reference
and there is no provision for a user-defined function to return a
reference." ES4 will not use references in the specification; this
will not prevent implementations from providing them, and there will
be some syntactic cruft in ES4 to allow ES3 programs written for IE to
continue to be syntactically valid.
p40 10.1.2. Second bullet, the language here is clumsy. AFAIK there
is no way to disable strictness, so the use of "switched" is not right
either.
p41 10.1.6. "mentions 'arguments' freely" needs to be explained in
more detail.
p41 10.1.8. Creating "callee" only for non-strict code breaks the
ES3.1 - ES4 subset relationship. Also, I have said it before and it
looks like I will have to continue to say it, the arguments object
*cannot* be an Array. The prototype object of the arguments object is
the original Array.prototype value, but that's all. Please see
extensive discussions in the wiki on this. (Making it an Array in
ES3.1 will break the ES3.1 - ES4 subset relationship.)
p42 10.1.1. We all hate this sharing, but you're stuck with it.
(Mind the subset relationship...)
p42 10.2.2. I think the current conclusion for ES4 is that variable
instantiation in the eval caller is OK as long as the caller is
non-strict, whether the eval code itself is strict or not does not
make a difference. I suspect this is the right tradeoff (you get
error checking inside the eval code). Also, you need to spec what
happens here. In ES4, the thought is that you get a SyntaxError from
eval if it tries to introduce top-level names and the context does not
allow it.
p47 11.2.3. The comment is irrelevant, because MSIE can be free to
extend semantics (and syntax for that matter) for its own purposes.
p64 12.2. Careful here, this should be [[Dynamic]]=false. For the
'var' statement, these properties are tagged DontDelete in the global
object. You're not right in asserting that FF allows them to be
deleted, as this script (which prints '10' twice in FF) shows:
var x = 10;
document.writeln(x);
delete x;
document.writeln(window.x);
Dynamically created globals (created by assignments only) are
different, they should be deletable.
p65 12.5. This comment is curious, apart from in catch handlers and
in named function expressions there are no block-local binding, and
even the latter case should probably be interpreted differently.
p69 12.10. Disallowing the with statement in strict mode breaks the
ES3.1 - ES4 subset relationship (we've found no compelling reason to
ban it).
p74 13. The comment asks, is it observable that the function is
stored in an enumerable property? The answer is yes. (The secret is
in 11.2.3 and in lines 1 and 2 of the present algorithm.) This should
print "n":
(function n(x) {
if (x) return this;
for (var v in n(true))
print(v);
})(false)
p76 14. I know you like strict mode, but presumably this pragma ought
to be optional, not mandatory.
p77 15#5. Looks like a gratuitous change. Motivation?
p78 15.1.1. Incompatible change, and incompatible with ES4 (which
makes these properties not only DontDelete and DontEnum, but ReadOnly
as well). The ReadOnly-ness in ES4 is unconditional (and so also
incompatible with ES3, strictly speaking); maybe going in that
direction will be better for ES3.1.
p78 15.1.2.1. ES4 strict mode will not require an EvalError to be
thrown, nor should ES3.1.
p85-87 15.2.3.2 - 15.2.3.15: these conflict in various ways with ES4
and will likely not be adopted by that language in the form they are
exhibited here. Specificially
- sealing, freezing, and prototype reading are unlikely to be in ES4
- beget is (though the description is missing I understand it creates
an object with a specific prototype value and a few specific
objects) handled by syntax and is not needed in ES4
- many of the other algorithms are probably best expressed in terms
of iterators and enumerators in ES4
- as earlier discussion has shown, we object (on aesthetic and
efficiency grounds) to some of these APIS.
No doubt we'll have much fun discussing this during future meetings.
p90 15.3.4.5. The description of 'bind' needs to be improved
substantially, it should be easy enough to express it using the normal
pseudocode or even ES3.
p90 15.3.5.2. Incompatible with ES4, breaks the subset relationship.
p90 15.4.3.2. Probably to spell out that this is required to work
across global objects and to note that 'instanceof' does not.
p100 15.4.4.14. I am reasonably confident that this algorithm is not
consistent with the one published as part of the JS1.6 spec:
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Objects:Array:indexOf
In particular, note how the latter algorithm only performs the ===
comparison if the index is present in the array, whereas steps 12-14
simply call [[Get]] and use the result. I am also not confident that
the bounds computations are equivalent.
(As it happens I'm not sure that the code on the mozilla site is 100%
what we want either, in particular, unlike array methods in ES3 it
does not appear to bound the length above at 2^32-1, for better or
worse).
Anyway, anything that isn't essentially 100% compatible with the
published 1.6 spec will also not be compatible with what's in ES4.
I have not checked the algorithms in the following sections.
p131 15.9.1.15. This is not acceptable: "Illegal values
(out-of-bounds as well as syntax errors) in the format string shall
cause Date.parse to return NaN". Date.parse needs to be required to
give preference to ISO format strings and strings that have the format
returned by Date.toString. Everything else is between Date.parse and
its maker.
p132 15.9.4.2. Same comment. The language here does not make sense.
First, it breaks the web -- Date.parse must cope with the many formats
out there right now. Second, it is internally contradictory: it says
that Date.parse shall return NaN if the ISO format is not met; then it
says something incoherent about implementation-defined heuristics.
p139 15.9.5.42. Propose you remove the NOTE here, which contradicts
the normative text. The string is supposed to be "human-readable"
which indicates something richer than ISO format.
p139 15.9.5.44. Date.prototype.toJSON is not going to be in ES4, and
IMO it does not belong here.
p155 15.10.7.5. I don't understand this comment.
p158 15.12. We have not considered JSON for ES4 and will probably
need some time to determine whether this API is suitable (presumably
after this section has been completed; it appears to be in an
intermediate state).
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
