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

Surya was asking about:

x->{a->b;}

which contains a semicolon; I'm not sure that my original suggestion
correctly handles the semicolon.

Your reasoning about

logic Z = a ? b : c->d;

assumes an LALR parser. But there is no requirement that we use an
LALR parser. Using a top-down parser, constraint_set would never be
considered for the above since we are not processing a constraint.
(And Yacc has far better syntax error recovery than most of the
commercial simulators I've used leading me to believe that the
commercial simulators use hand-coded recursive-descent parsers.  Must
be fun to maintain.)

Steven Sharp's comment is interesting. On the one hand it's not an
unreasonable viewpoint to take. On the other, how can we be sure that
the SystemVerilog grammar is indeed unambiguously specified if it is
not presented in a way that lends itself to rigorous analysis?

I have been tinkering with Verilog and VHDL parsers for some time.
Perhaps I'm thoroughly unqualified, but I have found that neither
language can be processed by either an LL(1) or an LALR(1) parser
generator "as-is". Some tinkering is required. This is not unexpected
- many languages have such quirks in their published grammars. But if
extensive massaging (and supplementary semantic checks to catch
erroneous constructs admitted by the modified
parser-generator-friendly grammars) is required then I for one can't
be sure that we've properly specified the language. As a compiler
writer (wannabe) I can't be sure that my tinkered grammar properly
implements the language.

I am not asking that the grammar be presented in a form that is
clearly LL(1) or LALR(1). Perhaps the published grammar could be
suitable only for a parsing algorithm that can verify some basic
properties of the grammar, but in practice runs far too slowly to be
practical. But if we allow demonstrably ambiguous constructs in the
grammar we ought to be able to prove that they are semantically
equivalent. Has any effort to this end been done?

(Worthy of consideration: I think the Java language spec presents its
grammar, and then follows with a chapter on "the preceding is not
acceptable to an LALR(1) parser generator. Here are the trouble spots,
and how to hack them." Doing the same for Verilog might be useful.)

All of this, of course, is a task for after the 2008/2009 version of
the standard is passed.

On Mon, Apr 6, 2009 at 2:34 PM, Greg Jaxon <Greg.Jaxon@synopsys.com> wrote:
> Surya,
>
>      I might be misreading somewhere, but I had very different issues with
> David's proposal for an LALR-like restatement of the LRM's grammar.
>
> Firstly I don't think it rules out the example you cited "x->{a->b;}",
> because a is an expression_no_implication, leaving b as the constraint_set
>
> But I also didn't follow David's analysis of a->b->c;  I'm pretty sure that
> a, b, and c will
> all become expression_no_implication and will be stacked until the ";" is
> seen.
> At that stage won't a yacc-like parser work on the tokens nearest the cursor
> first?
> It should reduce c to expression, and then see the following token stacks:
>  expression_no_implication   ->   expression <cursor> ;
>
> I haven't tried David's formulation yet, but he assumes the look ahead
> tokens ";" vs, say  ")"
> will decide the issue.   I'm not convinced; consider:
>     logic Z = a ? b : c->d;
> it produces the same ending condition of the parser stack, but here
> constraint_set is
> the wrong route to take.
>
> Greg
>
>
> Surya Pratik Saha wrote:
>
> Also, considering your solution, following example:
>         constraint C {
>             x -> { a -> a;}
>         }
> will become illegal, which is now legal.
>
> Regards
> Surya
>
>
> -------- Original Message  --------
> Subject: Re:[sv-bc] Conflict for implication (->) operator
> From: Surya Pratik Saha <spsaha@cal.interrasystems.com>
> To: David Jones <djones@xtreme-eda.com>
> Cc: "sv-bc@eda.org" <sv-bc@eda.org>, "sv-ec@eda.org" <sv-ec@eda.org>
> Date: Monday, April 06, 2009 7:33:21 PM
>
> 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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.