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

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.