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

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.