RE: [sv-bc] Question about "let"

Thanks for correcting me, Shalom.  This is excellent information.

But I'm not sure about the distinction you're making between the actuals 'a' and 'b+1' here.  According to the BNF, the actual 'a' is not an lvalue, but an 'expression'.

Is the expression nature of 'a' laundered away by 'let'?  Or is 'expression' only being used very loosely, as in the 'actual_argument' of Syntax 22-3?

-- Brad

________________________________________
From: owner-sv-bc@eda.org [owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom [shalom.bresticker@intel.com]
Sent: Thursday, June 04, 2009 7:07 AM
To: sv-bc@eda.org
Subject: RE: [sv-bc] Question about "let"

I discussed this with Dmitry.

First, the 'let' *is* a template. The LRM says, "A let declaration defines a template expression (a let body), customized by its ports."

The complete let expression is enclosed in parentheses where it is used. The LRM says, "The result of the substitution is enclosed in parentheses (...) so as to preserve the priority of evaluation of the let body."

However, this is not true of the substitution of the actual arguments for the formal arguments. This is done according to the rewriting algorithm in F.4.1.

A formal argument can be typed or untyped.

In Greg's example,

> >      let post_incr(v) = v++;
> >      let pre_incr(int v) = v++;
> >      int a = 0 , b = 0;
> >      b = post_incr(a);
> >      a = pre_incr( b+1 );

post_incr has an untyped formal argument.
pre_incr has a typed formal argument.

In the case of an untyped formal argument (e.g., v in post_incr), then if the actual argument is $ or a variable_lvalue, then it is substituted as is. "a" means this condition, "b+1" does not. If this condition is not met, the formal argument is replaced by the actual argument, with the addition of a cast: item(type(af)'(af)), where "af" is the actual argument. Note that the operand of the ++ operator is required to be an lvalue. b+1 is not an lvalue, so this will not be a legal value for this let construct.

If the formal argument is typed, as in pre_incr, even if the argument is an lvalue, the formal argument is replaced by a cast of the actual argument to the type of the formal argument. So for pre_incr, even if the argument were simply b, it would be replaced by int'(b), which again is not a legal lvalue, even though b itself is a valid lvalue.

A careful reading of the rewrite algorithm will show that the substitution of actual arguments for formal arguments is not necessarily a simple literal textual substitution, even with casts. It is more of a conceptual substitution. That is the purpose of "item", which is described in the 3rd paragraph of F.4.1.

Dmitry, please correct me if I got any of this wrong.

Regards,
Shalom

> -----Original Message-----
> From: owner-sv-bc@server.eda.org
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Greg Jaxon
> Sent: Tuesday, June 02, 2009 12:00 AM
> To: Brad Pierce
> Cc: SV_BC List
> Subject: Re: [sv-bc] Question about "let"
>
> In C++, that wouldn't do the trick, but in SV it appears to
> make all the
> difference, Thanks!
>
>
> Brad Pierce wrote:
> > Greg,
> >
> > When the actual for v gets substituted in, isn't it wrapped
> in parens, yielding something illegal, such as
> >
> >               (x)++
> >
> > -- Brad
> >
> >
> > ________________________________________
> > From: owner-sv-bc@eda.org [owner-sv-bc@eda.org] On Behalf
> Of Greg Jaxon [Greg.Jaxon@synopsys.COM]
> > Sent: Monday, June 01, 2009 1:03 PM
> > To: SV_BC List
> > Subject: [sv-bc] Question about "let"
> >
> > Are either of the following legal?
> >
> >      let post_incr(v) = v++;
> >
> >      let pre_incr(int v) = v++;
> >
> > If they are, what is the value of the actual arguments after the
> > following uses?
> >
> >      int a = 0 , b = 0;
> >      b = post_incr(a);
> >      a = pre_incr( b+1 );
> >
> > My understanding is that at the very least this last usage
> is illegal,
> > but perhaps not, if we regard let as having more of a
> functional than a
> > template interpretation.
> >
> > Greg Jaxon
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


--
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.