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

From: Surya Pratik Saha <spsaha_at_.....>
Date: Sun Apr 05 2009 - 22:09:55 PDT

Hi Brad,
I agree for special constraint phrases, the mentioning implication operator separately is necessary. But a constraint expression can reduce to normal expression as well. So the conflict would come. I think BNF changes necessary with this regard, or a special note should be there.

Regards
Surya

-------- Original Message  --------
Subject: Re:[sv-ec] Conflict for implication (->) operator
From: Brad Pierce <Brad.Pierce@synopsys.com>
To: sv-bc@eda.org <sv-bc@eda.org>, sv-ec@eda.org <sv-ec@eda.org>
Date: Sunday, April 05, 2009 9:12:21 PM

Surya,

  

I think constraint expression rule should not have the operator,
as by binary expression it is already part of expression.
    

'constraint_expression' is not, as its name suggests, a restriction of 'expression', like 'constant_expression', but is instead a generalization of 'expression'.  In particular, 'constraint_expression' generates many phrases with '->' that could no longer be generated if the production "expression -> constraint_set" were removed. For example, what if the 'constraint_set' in the right operand of '->' used a distribution?

-- Brad

________________________________
From: owner-sv-ec@eda.org [owner-sv-ec@eda.org] On Behalf Of Surya Pratik Saha [spsaha@cal.interrasystems.com]
Sent: Sunday, April 05, 2009 7:55 AM
To: sv-bc@eda.org; sv-ec@eda.org
Subject: [sv-ec] Conflict for implication (->) operator

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<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. Received on Sun Apr 5 22:12:18 2009