Re: IEEE - Latest Constraints revisions

Darren wrote:
>
> Here is the new version of Chapter 10, Constraints, which has
> undergone working group review. Please could people review it and feed
> back any issues via the reflector. I'll also add the document to the
> downloads section of our website.
>
It appears as though the existing code sample convention, documented in
section 1.5 of the LRM is not adhered to in this new chapter.  Table 2
of section 1.5 reads:

    An item followed by a separator character (usually a comma or a
    semicolon) and an ellipsis is an abbreviation for zero or more
    elements of the specified type, each separated from the next by the
    separator character. For example, in the following line zero or more
    actions may appear between the braces, each separated from the next
    by a semicolon.

        if bool-exp [then] {action; ...}

Semicolons are repeatedly used as statement terminators, thereby
introducing null statements.

For example, the first set of examples in section 10.1, "Types of
Constraints," ought to be illustrated thus:

    1   x : int[1, 3, 5, 10..100];       \\ is the same as:

    2   x : int;
    3     keep x in [1, 3, 5, 10..100];

    4   l[20] : list of int;             \\ is the same as:

    5   l : list of int;
    6     keep l.size() == 20

(Note the absence of a semicolon on line 6.)  Another example is in
section 10.27.7.1.1 (PDF page 5), omitting the null statements:

    1   color <-> x <-> y
    2   <'
    3   extend sys {
    4     p: packet_s
    5   };

    6   struct packet_s {
    7     color: [RED,BLUE,YELLOW];
    8     x: uint;
    9     y: uint;

    10    keep color!=YELLOW => x < y;

    11    when RED packet_s {
    12      keep x < 100
    13    };

    14   when BLUE packet_s {
    15      keep x > 50
    16    }
    17  }
    18  '>

Lines 4, 12, 15, 16 and 17 require no semicolon.

In section 10.2.10, "Generatable paths and the sampling of inputs," on
PDF page 10 the paragraph:

    An otherwise generatable path can be defined as input to a
    constraint using the read_only() syntax, e.g., keep x<read_only(y).
    In this case, the set of values y can take is unaffected by the
    constraints on x.  The parameter y is treated as an input.

would be grammatically correct if written as:

    A non-generatable path can be transformed into a generatable path if
    it is defined as an input to a constraint using the read_only()
    syntax, e.g., keep x < read_only(y). In this case, the set of values
    y can take is unaffected by the constraints on x. The parameter y is
    treated as an input.

The paragraph that follows:

    Arbitrary expressions can be used as arguments of read_only(). For
    example, in keep x<read_only(y+z), both y and z become inputs of the
    constraint. The constraint resolution engine generates y and z
    (unaffected by the possible values of x) and computes their sum,
    which is then used as an input in the constraints.

discusses an implementation aspect of the */e/*language, Specman's
constraint resolution engine, which it should not.  I suggest:

    Arbitrary expressions can be used as arguments of read_only(). For
    example, in keep x < read_only(y+z), both y and z become inputs of
    the constraint. First y and z are generated (unaffected by the
    possible values of x). Then,their sumis computed and used as an
    input in the constraints.

The lists referenced in section 10.2.13.3.1, "l1" and "l2" ought to be
renamed so that the ell ("l") is not mistaken for a one ("1").  The
example could be changed to:

    extend sys {
      L1 : list of int;
      L2 : list of int;
     !x  : int;
        keep L1 == L2;

      post_generate() is also {
        x = L2.pop()
      }
    }

modifying the following two paragraphs accordingly.


-- 


    Andy@Piziali.dv.org <mailto:andy@piziali.dv.org> 	
    PGP Key ID: 6F66CA9F
<http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6F66CA9F>



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