RE: IEEE - Latest Constraints revisions

Hi Andy,

Regarding the semicolons - personally I don't think that putting that extra semicolon in examples would be wrong. Since a null statement (or action, or any other language construct that can be separated from others by a semicolon) is a valid one, such an example would still be correct.
Further, I think having a semicolon also after that last statement would be make it more readable.
However, since we already use that convention in existing examples, I'm OK with that.

Regarding the last two points:

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 sum is 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.

I agree with both suggestions.
Thanks,
Yuri.



From: owner-ieee1647@eda.org [mailto:owner-ieee1647@eda.org] On Behalf Of Andrew Piziali
Sent: Friday, July 18, 2014 21:40
To: Darren Galpin
Cc: ieee1647@eda.org
Subject: 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 sum is 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>

[cid:image001.png@01CFA5B7.83C72B60]

    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<http://www.mailscanner.info/>, and is
believed to be clean.

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