Subject: RE: [sv-ac] and, or, intersect
From: Armoni, Roy (roy.armoni@intel.com)
Date: Thu Feb 13 2003 - 05:04:53 PST
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
This archive was generated by hypermail 2b28 : Thu Feb 13 2003 - 05:06:01 PST