ES3.1 questions and issues

Mark S. Miller erights at google.com
Tue Mar 17 16:43:10 PDT 2009


Some ES3.1 questions and issues that some Googlers have asked me to relay:

* At the end of 7.8.5 is the sentence "If the call to new RegExp would
generate an error, the error must be reported while scanning the
program." Presumably, the intention of this sentence applies only to
syntax errors. For example, if the call to new RegExp would generate
an out of memory error, we should not imply that this must instead be
reported at scanning time.

* There is general confusion about when "scanning" is, i.e., what
temporal distinction is being made here. When I tried to clarify, I
found I may be confused as well. Can an implementation postpone
scanning a top level function until it is called? Until after earlier
top-level definitions and/or statements in its Program have been
evaluated?

* What about logical impossibilities like "/$.^/"? May an
implementation reject this at scan time? Must it? If not, then what
about during construction at runtime?

* I do not know that the verbal agreement (from the ES3.1 phone calls)
that I summarize below is adequately captured by the current draft
spec:

If a host object provides its own internal [[GetOwnProperty]] method,
the mutability implies by the descriptors it returns must be an upper
bound on the possible mutations of the described property. For
example, if an accessor (getter/setter) property is described as a
data property where the getter may return different values over time,
then the [[Writable]] attribute must be true. If the attributes may
change over time or if the property might disappear, then the
[[Configurable]] attribute must be true. If [[Writable]] and
[[Configurable]] are both false and the property is described as a
data property, then the host is effectively promising that the gotten
value will be stable and may validly be cached.

Is this guarantee adequately captured? Where?

* Annex B lists some aspects of consensus JavaScript as implemented by
some major browsers but purposely omitted from the normative spec.
However, other aspects of consensus JavaScript are not listed in Annex
B. Should they be?
__defineGetter__, __defineSetter__, __proto__
nested function definitions, const
non-strict arguments.caller, <function>.caller, <function>.arguments
And now that <function>.toString()'s behavior has reverted to
unspecified, do we want to suggest particular behavior in Annex B?

* Array.prototype.sort was a particularly tricky thing to specify,
since we do not wish to specify which sorting algorithm an
implementation must use, even though the resulting differences are
observable by side-effecting comparefn, getters, and setters. Were we
to specify any normal sorting algorithm in our normal pseudo-code
algorithmic style, the sort() function itself would [[Get]] "length",
make some set of [[Get]]s, [[Put]]s, [[Delete]]s, on numerically named
properties between 0 and length-1, where values [[Put]] would only be
values obtained from previous [[Get]]s, and would make some set of
calls to comparefn, using only values obtained from previous [[Get]]s.
Each of these operations may behave badly in a number of ways, in
which case the specified sort routine will fail to sort. But the only
side effects sort would cause would be that brought about by calling
these other operations. If any of these operations throw, I would
expect sort() not to intercept it but to let it propagate, terminating
the sort().

Notice that I said all that without naming a specific sort algorithm.
Would it be reasonable to tighten the sort spec, including the sort
failure spec, in this way?

IIUC, [[Delete]] is only included so that a sort algorithm can pack an
array with holes in it if it wishes. Is this behavior important? Could
we instead tighten the spec to add a requirement that the supposed
array be packed? What does sort() do on existing browsers on arrays
with holes?

* For the identifiers we are already confident will become keywords as
of ES-Harmony -- "const" and "let", perhaps "yield" and "lambda" --
would it make sense to make these keywords now in strict code?




-- 
    Cheers,
    --MarkM


More information about the Es-discuss mailing list