[sv-ac] Draft 7 review[SPAM]

From: John Havlicek <john.havlicek_at_.....>
Date: Mon Sep 22 2008 - 08:30:18 PDT
Hi All:

Below are the results of my Draft 7 review.  I've entered notes
in Mantis and switched from completed to editor state where 
appropriate.

Note that some of these recommendations may require SV-AC approval
before the editor will act on them.

J.H.

Draft 7 Review:
---------------

1549 (bug note 7087)
 The bug note specified one paragraph for the two sentences in 16.8
  describing name resolution.  Draft 7 has them in separate paragraphs.
  I think that the separate paragraphs can be left as they are or 
  joined into one.
 The change of property to courier bold in the third paragraph of 16.13.18
  was done in the first sentence, but not in the second.  There is also an
  instance of the phrase "of type property" in the second paragraph of 16.13.18
  that should follow the same font convention.  The bug note did not specify 
  the multiple occurrences explicitly.
 In F.2, The references to item that existed before 2434 have been italicized.
  However, 2434 adds a reference to item that is not italicized.  I think that 
  the font should be roman italic, not courier italic.  There are also two 
  other references to item added by 2434 in F.5.2.1, one in 3)b) of 
  flatten_property(p), and one in 3)b) of flatten_sequence(r).  Their fonts 
  should be made consistent as well.
 By the way, the rewriting algorithm subsections (F.5.2, F.5.3) do not belong in 
  F.5 (Extended expressions).  They should be in their own F.x section called
  "Rewriting algorithms".  This may have resulted from mistaken instructions in
  the proposals, but it does not make sense to have them underneath "Extended
  expressions".

1648 (bug notes 7089 and 7206)
 In 16.16, I think that assertion a8, the always procedure that contains it,
  and the preceding comment should be deleted.  This is because concurrent 
  assertions in procedural code have been changed by SV-SC, and this example
  is not consistent with those changes.

1667 (bug note 7167)
 No issue found.

1667 (Annex F)
 F.5.2.1, flatten_property(p), 6).  Mantis 2434 has eliminated the capability
  for default actual arguments to reference formal arguments.  Therefore the
  linear ordering described in this step needs to be stricken.  This obviates
  the need to answer the editor's question; for those interested, the correct 
  reference is to 16.13.19.  I recommend deleting the following:

     Determine a linear ordering of the local variable formal arguments of p' so
     that one local variable formal argument is guaranteed to precede a second
     local variable formal argument if the second local variable formal argument
     has a default actual argument that references the first local variable
     formal argument. According to 16.8.2, each local variable formal argument
     of a property is of direction input.

  I recommend changing

     Arrange these local variable declarations to be in the linear order chosen 
     above.

  to

     These local variable declarations may be arranged in any order.

 F.5.2.1, flatten_sequence(r), 6).  Mantis 2434 has eliminated the capability
  for default actual arguments to reference formal arguments.  Therefore the
  linear ordering described in this step needs to be stricken.  I recommend 
  deleting the following:

     Determine a linear ordering of the local variable formal arguments of r' so
     that one local variable formal argument is guaranteed to precede a second
     local variable formal argument if the second local variable formal argument
     has a default actual argument that references the first local variable
     formal argument.

  I recommend changing

     Arrange the local variable declarations added to the beginning of the body
     of r' to be in the linear order chosen above.

  to

     The local variable declarations added to the beginning of the body of r'
     may be arranged in any order.

 F.5.2.1, flatten_sequence(r), 6)b) and 6)c).  In each, change roman "sequence expr"
  to roman italic "sequence_expr" near the end of the sentence.
 Editor's question after flatten_sequence(r) in F.5.2.1.  The reference to 16.8.2 
  is correct.

1668 (bug note 7169)
 Not implemented in Draft 7.

1668 (bug note 7170)
 No issue found.  The editor did not implement the section renumbering suggested.
  The editor recommends that SV-AC approve this change.  The suggestion has been
  repeated in comments for 1549.

1687 (bug note 7171)
 No issue found.

1698 (bug notes 7090 and 7131)
 16.9.3, in the paragraph beginning "$past returns the value of expression1".  Change
  in two places

     ev if, and only if, expression2

  to

     ev iff expression2

  as in the proposal.  The fonts should be italic for "ev" and "expression2" and 
  bold courier for "iff".

  Rationale:  "ev iff expression2" is itself an event expression and is precisely 
  the event expression that is required for this discussion.

1734 (bug note 7166)
 No issue found.

1806
 In Syntax 16-20, add

    | restrict_property_statement

  to the RHS of the production for concurrent_assertion_statement.

2100 (bug note 7064)
 In F.4.1, the editor has faithfully rendered T^p as shown in the 
  proposal, but this font will need to be aligned with the font of 
  T^p from the Annex F changes from 1932.  The T is supposed to be
  in a calligraphic font.

2173
 In Syntax 16-16 and Annex A.2.10, RHS of production for property_declaration, 
  there should be no red ";" following property_statement_spec.
 16.13.16, the horizontal line at the top of Syntax 16-19 is missing.
 F.3.4.6, the sentence beginning "Where specify(b) is ..." needs to apply to all
  the items with case property statements.  The proposal shows this text shifted
  to the left.  I think it will be better to put this text before the items with
  case property statements and change the wording to "Let specify(b) be ...".

2327
 In 16.15.8, item ac), change

     if, and only if, the evaluation attempt of property_expr1 is nonvacuous and
     either expression_or_dist never holds or the evaluation of property_expr
     ends before the first clocking event where expression_or_dist holds for the
     first time.

  to

     if, and only if, the underlying evaluation attempt of property_expr is
     nonvacuous and expression_or_dist does not hold in any time step of that
     evaluation attempt.

  as in the proposal.  The language for items ab) and ac) needs to be aligned.
 In 16.15.8, item ad), I think that the expression_or_disti and property_stmti
  should be set using the same font conventions in the case property statement
  and in the explanation.  I prefer the italic font with subscripts as in the 
  proposal.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Sep 22 08:31:33 2008

This archive was generated by hypermail 2.1.8 : Mon Sep 22 2008 - 08:32:23 PDT