[sv-ac] Question about the semantics of operator precedences

From: Johan Mårtensson <johan.martensson_at_.....>
Date: Wed Jan 16 2008 - 01:29:35 PST
Hi Brad,

I was told by John Havlicek that you would be the right person to ask the
kind of question I am going to ask.

In SV-AC we are working on the addition of some property operators and
we have got stuck a little in a discussion on the meaning of operator
precedences as they are stated in the SV LRM.

Consider the following example

1) a ##1 b throughout s

The productions for ##1 and throughout are (somewhat simplified)

sequence_expr ::= 
 | expression
 ...
 | sequence_expr ##1 sequence_expr
 ...
 | expression throughout sequence_expr
 ....

Let a and b be expressions and s a sequence_expr. 'a ##1 b' is not an
expression so the only grouping which is not a syntax error is

2) a ##1 (b throughout s)

Now in the precedence table (Table 16-25 in D4) ##1 is given higher
precedence than 'throughout'.

a) According to my understanding because of the way an LR1 parser works (1)
will be grouped as (2) regardless of the relative precedences of '##1'
and 'throughout'. I.e. the precedence rules will only be used when there
is a conflict between two syntactically legal groupings, for example in
a shift-reduce conflict.

b) On the other hand one could (as some people on the committee do) interpret
the precedence rules to imply that (1) is a syntax error, because the
rules would favor the grouping '(a ##1 b) throughout s'.

The question is, should the precedence rules as stated in the LRM be
interpreted on the lines of (a) or of (b)?

Best Regards,

Johan Mårtensson


-- 
------------------------------------------------------------
Johan Mårtensson                 Office: +46 31 7451913
Jasper Design Automation         Mobile: +46 703749681 
Kvarnbergsgatan 2                Fax: +46 31 7451914
411 05 Gothenburg, Sweden        Skype ID: johanmartensson
------------------------------------------------------------

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Jan 16 01:30:08 2008

This archive was generated by hypermail 2.1.8 : Wed Jan 16 2008 - 01:32:55 PST