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

From: Surya Pratik Saha <spsaha_at_.....>
Date: Mon Apr 06 2009 - 07:03:21 PDT

Hi David,
Right now, a constraint_expression is recursively reduced to constraint_set too.

constraint_set ::=
constraint_expression

Then, we need to define a separate constraint_set, for which '->' is allowed to be binary expression as part of that. I think it will become very complex.

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:48:09 PM

I don't mean that. You would define two rules:

expression ::= expression_no_implication
   | expression_no_implication -> expression

expression_no_implication ::= (what we have today for expression, but
without including -> in binary_operator)

At this point anyone referencing "expression" won't notice anything
different. We've just factored out the implication operator.

You then replace the production:

constraint_expression ::= expression -> constraint_set

with:

constraint_expression ::= expression_no_implication -> constraint_set

(other productions for constraint_expression are unaffected.)

A statement such as "a -> b -> c" should right-associate as it always
did. "a" reduces to expression_no_implication, and "b -> c" matches
the expression call in expression_or_dist.

On Mon, Apr 6, 2009 at 8:58 AM, Surya Pratik Saha
<spsaha@cal.interrasystems.com> wrote:
  

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 07:05:21 2009