Steve and Paul,
Attached are corrections to P1076-2000/D1.
Cheers,
PA
-- Peter J. Ashenden Email: petera@cs.adelaide.edu.au Dept. Computer Science peter.ashenden@acm.org University of Adelaide peter.ashenden@computer.org Adelaide, SA 5005 Phone: +61 8 8303 4477 Australia Fax: +61 8 8303 4366WWW: http://www.cs.adelaide.edu.au/~petera (includes PGP public key) --------------EE2B3F1247BE9642411CDD36 Content-Type: text/plain; charset=iso-8859-1; name="P1076-2000-D1-corrections.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="P1076-2000-D1-corrections.txt"
Corrections to P1076-2000/D1
Peter Ashenden 25 November 1999
p. 64 Rev bar missing for insertion (footnoted 20)
p. 64 Change "Morover" to "Moreover".
p. 66 The revision of the wording for an in-mode interface object doesn't make sense. I suggest the following:
in. The value of the interface object must not be updated. Reading an attribute of the interface object is allowed, unless the interface object is a subprogram signal parameter and the attribute is one of 'STABLE, 'QUIET, 'DELAYED or 'TRANSACTION.
p. 81 The sentence containing footnote 22 specifies that an incremental binding indication must not have an entity aspect. However, the new paragraphs on p. 82 specify rules for an explicit entity aspect in an incremental binding indication, implying that an incremental binding indication may have an entity aspect. This is a contradiction, which is also contained in the LCS.
I believe the intent was that an incremental binding indication may or may not have an entity aspect, and if it does, then the entity aspect must conform to the rules on p. 82. The solution is simply to delete the sentence containing footnote 22. Note 2 on p. 82 should also be changed to say that
The entity aspect of an incremental binding indication in a component configuration is optional.
I think that is the intention of the note.
p. 82 Note 1 contains a typo: "applo" should be "apply to".
p. 82 Note 3 says that if a component configuration contains no entity aspect, generic map aspect or port map aspect, then there is no binding indication present. However, the syntax rules are:
component_configuration ::= for component_specification [ binding_indication ; ] [ block_configuration ] end for ;
binding_indication ::= [ use entity_aspect ] [ generic_map_aspect ] [ port_map_aspect ]
This suggests that a binding indication can be empty, but the semicolon that follows betrays its presence! For example:
for L : comp ; -- empty binding indication end for;
The semantics of this are that it is an incremental binding indication (otherwise it must have ane entity aspect) that does no rebinding.
It may be desirable to retain the specification that it is an error if an incremental binding indication has neither a generic map aspect nor a port map aspect. This would avoid the above strange construction. Note 3 on p. 82 should then be deleted. If you don't want to include an incremental binding indication, just omit the semicolon. The grammar then says there isn't one there!
If we retain the specification mentioned above, then Note 1 can be clarified. (It doesn't make sense to me as it stands.) 5.2.1.1 says that if a binding indication contains an entity aspect of the third form (open), then the binding indication must not include a generic map aspect or a port map aspect. Since (with the above specification) an incremental binding indication must contain a generic map aspect or a port map aspect, it cannot have an open entity aspect. So Note 1 on p. 82 should be revised to say that the third form of entity aspect does not apply to incremental binding indications for this reason. There is nothing in the rules on pp. 81 that prevents a primary binding indication with an open entity aspect having an incremental binding indication.
p. 80 While on the subject of incremental binding, there is a related issue that I have raised in previous comments, but that continues to be overlooked. I had suggested it be rolled in with LCS 8.
1.3.2 states:
If the component configuration contains a binding indication (see 5.2.1), then the component configuration implies a configuration specification for the component instances to which it applies. This implicit configuration specification has the same component specification and binding indication as that of the component configuration.
In the case of incremental binding, this means there are two configuration specification for a component instance: the explicit primary binding indication, and the implicit incremental binding indication.
5.2 states:
The elaboration of a configuration specification results in the association of binding information with the labels identified by the instantiation list. A label that has binding information associated with it is said to be bound. It is an error if the elaboration of a configuration specification results in the association of binding information with a component label that is already bound.
Taken with 1.3.2, this means that an error occurs when incremental binding is used: elaboration of one of the configuration specifications binds the complonent instance label, and so elaboration of the other results in an error!
The intention is that there cannot be more than one configuration specification for a given component instance unless it arises from an incremental binding indication. IMHO, it should also be an error if there is more than one incremental binding indication for a given component instance (although Steve disagrees with this.)
I suggest this be fixed by revising 5.2 as follows:
... It is an error if the elaboration of a configuration specification results in the association of binding information with a component label that is already bound, unless the binding indication in the configuration specification is an incremental binding indication (see 5.2.1).
If we also want to prohibit multiple incremental binding indications for a given component instance, further add:
It is an error if the elaboration of a configuration specification containing an incremental binding indication results in the association of binding information with a component label that is already incrementally rebound (see 5.2.1).
p. 92 Why insert "at least"? How can a name fall under more than one of the listed conditions?
Change "a attribute" to "an attribute".
p. 109 Footnote 12: Change "TO" to "To". Also occurs in footnote 13 on p. 110. May also occur elsewhere, but I'm not that extreme a pedant to search for them all manually. ;-)
p. 118 Delete ";" at end of the Note. Also on pp. 182, 191, 256. There may be other occurrences that I've missed - I didn't look very thoroughly. Would be easier to search using the word processor.
p. 137 Change "parocess" to "process".
Also, the revision has negated the sense of the rule. I suggest something like:
It is an error if a process or concurrent statement, other than a passive process or a concurrent statement that is equivalent to a passive process, appears in ...
p. 175 Clause 3.4.1 cross-references clause 12.5 regarding blocking on file operations, however, clause 12.5 is silent on this matter. I suggest revising clause 12.5(b) as follows:
... Next, if the subprogram is a method of a given [why "given"?] protected type (see 3.5.1) or an implicitly declared file operation (see 3.4.1), the elaboration blocks, if necessary, until exclusive access to the object denoted by the prefix of the method or to the file object denoted by the file parameter of the file operation is secured.
p. 183 Í (I-acute) is missing from the list of uppercase letters. It should be inserted between Ì (I-grave) and Î (I-circumflex).
pp. 183-184 Strange things have happened to some of the non-ASCII Latin-1 characters in the list of uppercase characters, the list of lowercase characters, the list of other special characters, and the table in Note 4.
p. 184 Change "the last subclause of this section" to "clause 13.10" to ease further maintenance of the document.
p. 191 Add a Note indicating that replacement characters may be removed in a later version of the language, referring to Annex F.
p. 202 Change "appropaite" to "appropiate".
p. 203 Change "appropaite" to "appropiate".
p. 203 In the example, the following corrections should be made:
-- Proc'PATH_NAME = ":lib:p:proc[integer]:" -- Proc'INSTANCE_NAME = ":lib:p:proc[integer]:"
p. 204 In the example, the following corrections should be made:
-- x'PATH_NAME = ":lib:p:proc[integer]:x" -- x'INSTANCE_NAME = ":lib:p:proc[integer]:x"
-- Proc1'PATH_NAME = ":e:proc1[natural,integer]:" -- Proc1'INSTANCE_NAME = ":e(a):proc1[natural,integer]:" -- C'PATH_NAME = ":e:proc1[natural,integer]:c" -- C'INSTANCE_NAME = ":e(a):proc1[natural,integer]:c" -- max'PATH_NAME = ":e:proc1[natural,integer]:max" -- max'INSTANCE_NAME = -- ":e(a):proc1[natural,integer]:max"
Note the insertion of the space and quotation marks that are missing in the value of Proc1'INSTANCE_NAME.
pp. 208-209 Strange things have happened to some of the non-ASCII Latin-1 characters in the definition of CHARACTER (7 occurrences).
p. 241 In B.56, the declarative region of an entity is used as an example of a disjoint declarative region. However, LCS 3 makes entity declarative regions no longer disjoint. I suggest revising the example to use package declarative regions, as follows:
... for example, the declarative region of a package declaration, which, if there is an associated package body, extends to the end of that package body.
--------------EE2B3F1247BE9642411CDD36--