RE: [sv-ac] and, or, intersect


Subject: RE: [sv-ac] and, or, intersect
From: dudani@us04.synopsys.com
Date: Thu Feb 13 2003 - 08:40:45 PST


I agree with Roy's proposal(d).
Surrendra
At 03:04 PM 2/13/2003 +0200, you wrote:
>Hi all,
>
>In addition to Cindy's proposal below, I would like to make proposal d:
>or will be changed to || (same as Verilog).
>and will be changed to && (same as Verilog).
>intersect will remain as in the current LRM.
>
>The reasoning is as follows:
> >From the specification point of view, the "and" operator on sequences
>actually agrees with the Boolean connective AND. When we specify ( s and t
>) we mean that s has to happen AND t has to happen. Since this is an
>extension of the && operator of Verilog in the sense that for sequences s,t
>of length one, ( s and t ) agrees with ( s && t ), I propose to use the same
>notation.
>
>A similar argument applies to why "or" should be changed to ||.
>
>As for the intersect operator, IMO we should not choose anything that
>resembles AND. The reason is that ( s intersect t ) does not mean that we
>apply the Boolean connective AND to the sequences s,t. It means something
>stronger, which also requires a length match between the two sequences.
>When interpreting s,t as regular expressions, this is indeed intersection.
>Thus, in the absence of anything better that does not resemble AND, I
>propose to remain with "intersect".
>
>An additional point that was raised during our last meeting is that "and" on
>sequences should be different than "&&" on expressions. I believe that it
>was Erich who gave the example of
>a ; b && c ; d
>that would be interpreted as
>a ; (b && c) ; d
>while in
>a ; b and c ; d
>the interpretation would be of
>(a ; b) and (c ; d)
>My answer was that in both cases the interpretation is not obvious. What we
>should do is to define a precise precedence for all the additional sequence
>operators.
>In any case, it will not be a good idea to overload the language with
>redundant symbols for similar operators in order to solve issues of
>precedence. IMO, a better choice would be to define precedence and use
>parenthesis wherever necessary.
>
>Regards,
> Roy
>
>
>
>-----Original Message-----
>From: Cindy Eisner [mailto:EISNER@il.ibm.com]
>Sent: Thursday, February 13, 2003 12:21 PM
>To: sv-ac
>Subject: [sv-ac] and, or, intersect
>
>
>
>all,
>
>i am not sure that i understand the rules for what we can propose and what
>we cannot, or even if any such rules have been laid down and by who. i
>disagree strongly that arguing syntactic matters is going to take up a lot
>of time. making a proposal takes a few seconds, discussion can be by email
>since the matter is a simple one, and voting is going to be by email also,
>as i understand it, so will require typing one additional character.
>
>in addition, i feel strongly that syntactic matters are important. like a
>good gui for a tool, good syntax has a huge influence on how a language is
>received by the user community.
>
>therefore, i am going continue with my proposal for changing the keywords
>"and", "or", and "intersect", for the following reason:
>
>it really bothers me that "or" is the union of regular languages, but "and"
>is not intersection. i think that we should either have the correspondence
>or-union, and-intersection, or not. so i suggest one of the following:
>
>proposal a:
>
>union be represented by the keyword "union"
>intersection be represented by the keyword "intersection"
>current keyword "and" stays "and"
>
>proposal b:
>
>union be represented by the keyword "or"
>intersection be represented by the keyword "and"
>current keyword "and" becomes "pand" (for prefix-and, because it requires
>the intersection of a prefix of one with the entire length of the other.
>this is reminiscent of using "xor" for "exclusive or")
>
>proposal c:
>
>union be represented by "||"
>intersection be represented by "&"
>current keyword "and" be represented by "&&"
>
>note that proposal "c" is *not* what we have today in psl, which uses "|",
>"&&", and "&" for union, intersection, and current "and", respectively. i
>like the argument (sorry, i didn't identify the voice of whoever made it)
>that a verilog bit-wise operator is appropriate when the lengths must
>match, and a verilog logical operator when they needn't match.
>
>regards,
>
>cindy.
>
>Cindy Eisner
>Formal Methods Group Tel: +972-4-8296-266
>IBM Haifa Research Laboratory Fax: +972-4-8296-114
>Haifa 31905, Israel e-mail:
>eisner@il.ibm.com

**********************************************
Surrendra A. Dudani
Synopsys, Inc.
377 Simarano Drive
Suite 300
Marlboro, MA 01752

Tel: 508-263-8072
Fax: 508-263-8123
email: dudani@synopsys.com
**********************************************



This archive was generated by hypermail 2b28 : Thu Feb 13 2003 - 08:41:23 PST