From: Karen L. Pieper (pieper@synopsys.com)
Date: Thu Jul 16 1998 - 18:05:06 PDT
BAD MSG:
I've been discussing this proposal with a member of the VCS implementation
eam. He has the following problems with the proposal, and would choose
a different syntax.
Content-Length: 1497
X-Lines: 49
X-Status: $$$$
X-UID: 0000000557
Status: RO
Given his parsing insights, I'm inclined to believe that our current
proposal is severely flawed.
Karen
<p>----- Begin Included Message -----
>From pae@synopsys.com Thu Jul 16 17:57:56 1998
From: pae@synopsys.com
Date: Thu, 16 Jul 98 17:57:25 PDT
To: "Karen L. Pieper" <pieper@synopsys.com>
Subject: Re: BTF - B13 - Mutable part selects proposal
I am sorry, I did not look at the BNF in detail.
I now see that the proposal restricts the input
to something that is computable at compile time.
However, it is still a bit ugly:
The idea of matching expressions bothers me. It is
no longer a context free grammar. How do you parse:
[r1-r2 : r1-r2 - c1 - c2] ?
or [r1-r2 - c1 - c2 : r1-r2] ?
According to the grammar it would be:
[(r1-r2) : (r1-r2) - (c1 - c2)]
but that is different than the normal associativity rules
for expressions which would be:
[(r1-r2) : (((r1-r2) - c1) - c2)]
If (r1-r2) is a constant expression, then it is unspecified
what the result will be, not does it make sense to parse
differently depending upon whether a subexpression is
constant or not. I think that we are treading on
syntax territory as bizarre as Fortran.
Also if there is a function call or other operators
with side effect in the expression, are you
supposed to compute the expression once or twice?
I would still much rather have bit position and bit count
as explicitly separate expressions. Maybe:
a[[i]c]
or a[[i:c]]
or a[i::c], etc.
-Peter
<p>----- End Included Message -----
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:57 PDT
and
sponsored by Boyd Technology, Inc.