Much longer and clearer than the old section 10, and much improved.
However, there remain some parts where I got confused and which could
perhaps be further improved/clarified.
A few minor typo/grammar issues still remaining too.
There seems to be some room for confusion between "identifiers" and
"names". Are they synonyms? Sometimes "N" or "name" is used to refer
to an identifier; there are mentions of "formal parameter names" (are
these identifiers?), etc. Also, are identifiers synonymous with
strings? Sometimes "name" is used to denote a string (eg in 10.5,
definition of MakeArgGetter). Overall, I think a non-expert reader
might be left unclear as to the global naming conventions and
associated implicit types in the spec.
10.2.1: Method specification for GetBindingValue and SetMutableBiding
do not describe behavior when S is false. Should they?
10.2.1.1.2: Spec is slightly different (in phrasing at least, possibly
in meaning) than in 10.2.1. Is this intentional/necessary? In general,
redundancy in a spec may lead to ambiguity/inconsistency.
10.2.1.1.3: Order of methods differs from 10.2.1, with a (small) loss
of clarity. Also some grammar and spelling issues.
10.2.1.1.5: Repitition of earlier spec for CreateImmutableBinding,
with different phrasing and/or meaning, introducing possibility for
ambiguity/inconsistency.
10.2.2.1: Inconsistent naming with earlier paragraphs, eg "N" vs
"name", "S" vs "strict". Also typo ".."
10.5 Typo "When the CreateArgumentsObject() is call_ed_ ..."
10.5.1: Typo "If a_n_ arguments object .."
Some comments/feedback on the new section 10
(from http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft)
Much longer and clearer than the old section 10, and much improved.
However, there remain some parts where I got confused and which could
perhaps be further improved/clarified.
A few minor typo/grammar issues still remaining too.
There seems to be some room for confusion between "identifiers" and
"names". Are they synonyms? Sometimes "N" or "name" is used to refer
to an identifier; there are mentions of "formal parameter names" (are
these identifiers?), etc. Also, are identifiers synonymous with
strings? Sometimes "name" is used to denote a string (eg in 10.5,
definition of MakeArgGetter). Overall, I think a non-expert reader
might be left unclear as to the global naming conventions and
associated implicit types in the spec.
10.2.1: Method specification for GetBindingValue and SetMutableBiding
do not describe behavior when S is false. Should they?
10.2.1.1.2: Spec is slightly different (in phrasing at least, possibly
in meaning) than in 10.2.1. Is this intentional/necessary? In general,
redundancy in a spec may lead to ambiguity/inconsistency.
10.2.1.1.3: Order of methods differs from 10.2.1, with a (small) loss
of clarity. Also some grammar and spelling issues.
10.2.1.1.5: Repitition of earlier spec for CreateImmutableBinding,
with different phrasing and/or meaning, introducing possibility for
ambiguity/inconsistency.
10.2.2.1: Inconsistent naming with earlier paragraphs, eg "N" vs
"name", "S" vs "strict". Also typo ".."
10.5 Typo "When _the_ CreateArgumentsObject() is call_ed_ ..."
10.5.1: Typo "If a_n_ arguments object .."
- Cormac
Some comments/feedback on the new section 10 (from es3.1:es3.1_proposal_working_draft)
Much longer and clearer than the old section 10, and much improved. However, there remain some parts where I got confused and which could perhaps be further improved/clarified. A few minor typo/grammar issues still remaining too.
There seems to be some room for confusion between "identifiers" and "names". Are they synonyms? Sometimes "N" or "name" is used to refer to an identifier; there are mentions of "formal parameter names" (are these identifiers?), etc. Also, are identifiers synonymous with strings? Sometimes "name" is used to denote a string (eg in 10.5, definition of MakeArgGetter). Overall, I think a non-expert reader might be left unclear as to the global naming conventions and associated implicit types in the spec.
10.2.1: Method specification for GetBindingValue and SetMutableBiding do not describe behavior when S is false. Should they?
10.2.1.1.2: Spec is slightly different (in phrasing at least, possibly in meaning) than in 10.2.1. Is this intentional/necessary? In general, redundancy in a spec may lead to ambiguity/inconsistency.
10.2.1.1.3: Order of methods differs from 10.2.1, with a (small) loss of clarity. Also some grammar and spelling issues.
10.2.1.1.5: Repitition of earlier spec for CreateImmutableBinding, with different phrasing and/or meaning, introducing possibility for ambiguity/inconsistency.
10.2.2.1: Inconsistent naming with earlier paragraphs, eg "N" vs "name", "S" vs "strict". Also typo ".."
10.5 Typo "When the CreateArgumentsObject() is call_ed_ ..."
10.5.1: Typo "If a_n_ arguments object .."