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

According to my understanding, after the long conversation I had with Dmitry:

You're correct that "it was not the intent that one could implement 'let' simply by expanding all the 'let' instantiations like preprocessor macro invocations".

Yes, there are cases where the let call can be legal if the formal argument is untyped and illegal if the formal argument is typed. For example, post_incr(a) is legal, because a is substituted for v without a cast because v is untyped. However, pre_incr(a) is illegal, because a has to be cast to v because v is typed, and a cast is not a valid lvalue. This is a semantic restriction, not a syntactic one.

However, a cast can be a valid rvalue. So (a+b) would still be valid, because it is encased in "item()". As the LRM says, "Using the item function, the form item(type(logic[0:3])'({a,b}))[1:2] is legal." "item" can be thought of abstractly as an internal temporary or intermediate variable of the implementation.

Shalom

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce
> Sent: Sunday, June 07, 2009 9:48 AM
> To: sv-bc@eda.org
> Subject: RE: [sv-bc] Question about "let"
> 
> Surya,
> 
> > all the formal argument usage of "let" construct is substituted
> > by a casted expression of provided actual argument
> 
> Not all the actuals are cast, just those bound to formals for 
> which types have been declared.
> 
> The syntactic possibilities for using a 'let' formal as an 
> lvalue would be limited, because the body of a 'let' is just 
> an expression, unlike the much richer procedural body of a 
> 'function'. In an expression an lvalue could only appear in 
> an assignment expression such as '(v += 1)' or 'v++'.
> 
> But as you point out, the target of a select, such as 'v[5]', 
> has a family resemblance to an lvalue.  Neither sort of usage 
> would be syntactically legal if 'v' were replaced with a cast.
> 
> But I think the intent of the 'item()' function in F.4.1 was 
> to somehow have a cast without forbidding these usages, or at 
> least not the select usage.  For example, I think it was not 
> the intent that one could implement 'let' simply by expanding 
> all the 'let' instantiations like preprocessor macro 
> invocations, dumping the expansion out to a file, and reading 
> it back in.
> 
> Unfortunately, the last paragraph of F.4.1 somewhat dodges 
> that issue by using an actual that would be a legitimate 
> syntactic target of a select, specifically, '{a, b}'.  It's 
> perfectly legal to write '{a,b}[1:2]'.  So if the formal were 
> 'v' and the actual were '{a, b}', then it would be weird if 
> 'v[1:2]' were legal when 'v' is untyped, but illegal when it 
> is typed, just because of some behind-the-scenes cast.
> 
> However, what if the actual were '(a+b)'?  It's syntactically 
> illegal to write '(a+b)[1:2]', so to get the desired effect 
> one must wrap the primary in concat braces, as 
> '{(a+b)}[1:2]'.  But if the actual bound to 'v' is '(a+b)', 
> is 'v[1:2]' legal or illegal?  I think the intent was that it 
> is legal.  But F.4.1 doesn't make that interpretation airtight.
> 
> -- Brad
> 
> 
> ________________________________
> From: Surya Pratik Saha [spsaha@cal.interrasystems.com]
> Sent: Saturday, June 06, 2009 9:08 PM
> To: Bresticker, Shalom
> Cc: Brad Pierce; sv-bc@eda.org
> Subject: Re: [sv-bc] Question about "let"
> 
> Hi Shalom,
> If I understand correctly, as you have explained by 
> "rewriting algorithm", all the formal argument usage of "let" 
> construct is substituted by a casted expression of provided 
> actual argument, then any lvalue usage of formal argument or 
> bit/part select of formal argument becomes also illegal. In 
> other way, the usage which is legal on a casted expression 
> only becomes legal, remaining all will become illegal. Is it 
> the intention of LRM? Or casted expression is used here just 
> to explain the concept?
> 
> For e.g.
> let post_incr(v) = v [1:0];
> let pre_incr(int v) = v[1:0];
> 
> int a = 0 , b = 0;
> b = post_incr(a);
> a = pre_incr( b );
> 
> All above usage are illegal, because int'(b)[1:0] is or 
> type(a)'(a)[1:0] all are illegal. Please let me know if I am 
> missing here anything, or this is the intention?
> 
> Regards
> Surya
> 
> 
> 
> -------- Original Message  --------
> Subject: Re:[sv-bc] Question about "let"
> From: Bresticker, Shalom 
> <shalom.bresticker@intel.com><mailto:shalom.bresticker@intel.com>
> To: Brad Pierce 
> <Brad.Pierce@synopsys.com><mailto:Brad.Pierce@synopsys.com>, 
> sv-bc@eda.org<mailto:sv-bc@eda.org> 
> <sv-bc@eda.org><mailto:sv-bc@eda.org>
> Date: Thursday, June 04, 2009 8:10:45 PM
> 
> As I understand the rewriting algorithm, the actual_argument 
> is indeed an "expression", but the way it is rewritten 
> depends on whether it is an lvalue or $ or not. It has the 
> effect of determining whether it is rewritten with or without a cast.
> 
> Shalom
> 
> 
> 
> -----Original Message-----
> From: owner-sv-bc@server.eda.org<mailto:owner-sv-bc@server.eda.org>
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce
> Sent: Thursday, June 04, 2009 5:28 PM
> To: sv-bc@eda.org<mailto:sv-bc@eda.org>
> Subject: 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<mailto:owner-sv-bc@eda.org> 
> [owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org>] On Behalf Of
> Bresticker, Shalom 
> [shalom.bresticker@intel.com<mailto:shalom.bresticker@intel.com>]
> Sent: Thursday, June 04, 2009 7:07 AM
> To: sv-bc@eda.org<mailto: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>
> [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<mailto:owner-sv-bc@eda.org> 
> [owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org>] On Behalf
> 
> 
> Of Greg Jaxon 
> [Greg.Jaxon@synopsys.COM<mailto: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.
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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.
> 
> 
> 
---------------------------------------------------------------------
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.