On Mon, 20 May 2002, Jon Jagger wrote:
> ... I
> happened to come across it while toying with the idea of writing a program
> to test every sentence in the spec.
> As it stands I think the problem is that the wording of the spec needs
> tightening a smidgen.
I started putting some comments together on the wording of the spec but
went off the idea rapidly. This is because I'm unhappy with the
presentation in many places.
I thought that in a programming language standard/specification you
clearly identified those bits which are "normative" and those bits that
are "informative" (e.g., notes and examples). Section 7 of this spec
explains how it is intended to do this in this spec, but there are so
many occurrences where this does not happen.
I also thought that the normative bits should be stated once (and not
everywhere where you think it might be useful to the reader of the spec).
Unfortunately, many of the "repetitions" use different wordings (which is
not a great idea as it can easily lead to contradictions).
Below I give comments on two sections of the spec that I've chosen at
random and point out occurrences of these two problems.
I've taken the first example from "14.5.2.1 Invariant meaning in blocks".
> For each occurrence of a given identifier as a simple-name in an
> expression, every other occurrence of the same identifier as a
> simple-name in an expression within the immediately enclosing block
> (15.2) or switch-block (15.7.2) must refer to the same entity.
OK.
> This rule ensures that the meaning of a name in the context of an
> expression is always the same within a block.
The above is a note but is not identified as such.
> The example
> class Test
> ...
> is permitted because the name x is never used in the outer block.
The above text gives two examples but they are not correctly labelled as
being examples.
> Note that the rule of invariant meaning applies only to simple names.
> It is perfectly valid for the same identifier to have one meaning as
> a simple name and another meaning as right operand of a member access
> (14.5.4).
The above is a note but is not correctly labelled as being a note.
> [Example: For example:
> struct Point
> ...
> names x and y refer to the parameters, but that does not prevent
> the member access expressions this.x and this.y from accessing
> the fields. end example]
The above is OK (because it is identified as an example).
My second example is from "15.8.3 The for statement".
> The for statement evaluates a sequence of initialization
> expressions and then, while a condition is true, repeatedly
> executes an embedded statement and evaluates a sequence of
> iteration expressions.
As this just repeats what is given more formally later, I believe that
this sentence should be a note. In fact, it is probably the case that all
of the sentences that immediately precede the syntax clauses should be
notes.
> for-statement :
> for ( for-initializeropt ; for-conditionopt ; for-iteratoropt ) embedded-statement
> for-initializer :
> local-variable-declaration
> statement-expression-list
> for-condition :
> boolean-expression
> for-iterator :
> statement-expression-list
> statement-expression-list :
> statement-expression
> statement-expression-list , statement-expression
OK.
> The for-initializer, if present, consists of either a
> local-variable-declaration (15.5.1) or a
> list of statement-expressions (15.6) separated by commas.
This sentence should be a note as it just restates what is given in the
syntax clauses.
> The scope of a local variable declared by a for-initializer
> starts at the local-variable-declarator for the variable and
> extends to the end of the embedded statement. The scope includes
> the for-condition and the for-iterator.
This "duplicates" the text given in Section 10.7 ("Scopes"). However,
different wording is given in Section 10.7 which is always a worry because
this might lead to a contradiction. So the above text should be omitted
or turned into a note. If kept, use the same wording in both places.
> The for-condition, if present, must be a boolean-expression
> (14.16).
> The for-iterator, if present, consists of a list of
> statement-expressions (15.6) separated by commas.
These two sentences should be a note as it just restates what is given in
the syntax clauses.
> A for statement is executed as follows:
> ...
> control is transferred to the end point of the for statement.
OK.
> Within the embedded statement of a for statement, a break
> statement (15.9.1) may be used to transfer control to the end
> point of the for statement (thus ending iteration of the
> embedded statement), and a continue statement (15.9.2) may be
> used to transfer control to the end point of the embedded
> statement (thus executing another iteration of the for statement).
This sentence repeats what is given in more detail in Sections 15.9.1 and
15.9.2. So the above text should be omitted or turned into a note.
Aside: I'd also like to join those that have thanked JJ for his
hyperlinked version of the spec.
--
Barry Cornelius Telephone: (0191 or +44 191) 374 4717
User Services, Information Technology Service, Office: 374 2892
Science Site, University of Durham, Durham, DH1 3LE, UK Fax: 374 7759
http://www.dur.ac.uk/barry.cornelius mailto:[EMAIL PROTECTED]
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
