Re: [sv-bc] Conflict for implication (->) operator

From: Surya Pratik Saha <spsaha_at_.....>
Date: Mon Apr 06 2009 - 05:58:24 PDT

Hi David,
So then you want to mean, nobody can use '->' as part of binary expression inside constraint expression. That is too restrictive. LRM has to be clear on that. Otherwise, tools may try to fix at their own way.

Regards
Surya

-------- Original Message  --------
Subject: Re:[sv-bc] Conflict for implication (->) operator
From: David Jones <djones@xtreme-eda.com>
To: Surya Pratik Saha <spsaha@cal.interrasystems.com>
Cc: "sv-bc@eda.org" <sv-bc@eda.org>, "sv-ec@eda.org" <sv-ec@eda.org>
Date: Monday, April 06, 2009 6:02:50 PM

I was about to reply with an argument along the lines of:

Given: a -> b foo c

where "foo" represents an operator having lower precedence than '->',
then the grammar as-is would allow two conflicting parses which differ
in the relative precedence of foo and ->. As an expression, a -> b foo
c would mean:

(a -> b) foo c

if foo has lower precedence, but using the rules for constraint
expression it would mean:

a -> (b foo c)

As it turns out, -> already has almost the lowest precedence possible.
The only operators having lower precedence are the assignment
operators which, if they appear in an expression, must be
parenthesized. Although there are conflicting parses, I believe that
all conflicting parses will eventually have the same semantics.

Nevertheless, I think this can be fixed. The solution is to have two
rules, one for expression and the other for "expression but not using
the -> operator". The productions for constraint expression can then
reference the latter.


On Sun, Apr 5, 2009 at 10:55 AM, Surya Pratik Saha
<spsaha@cal.interrasystems.com> wrote:
  

Hi,
As per SV 2009 draft 7a LRM, implication operator (->) has become part of
binary expression. But it is already part of constraint expression. So it is
really conflicting situation wrt a parser. I think constraint expression
rule should not have the operator, as by binary expression it is already
part of expression. Here is the two BNF snippet:

constraint_expression ::=
expression_or_dist ;
| expression –> constraint_set
| if ( expression ) constraint_set [ else constraint_set ]
| foreach ( ps_or_hierarchical_array_identifier [ loop_variables ] )
constraint_set

constraint_set ::=
constraint_expression
| { { constraint_expression } }

expression ::=
primary
| unary_operator { attribute_instance } primary
| inc_or_dec_expression
| ( operator_assignment )
| expression binary_operator { attribute_instance } expression
| conditional_expression
| inside_expression
| tagged_union_expression

binary_operator ::=
+ | - | * | / | % | == | != | === | !== | ==? | !=? | && | || | **
| < | <= | > | >= | & | | | ^ | ^~ | ~^ | >> | << | >>> | <<<
| -> | <->

Is it an oversight of LRM?

--
Regards
Surya

--
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 Apr 6 05:59:35 2009