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.Received on Sat Jun 6 23:48:54 2009
This archive was generated by hypermail 2.1.8 : Sat Jun 06 2009 - 23:49:44 PDT