RE: [sv-bc] Re: [sv-ec] Updated proposal for 'let' syntax

Sequences and properties have the same problem with inlining. 
They are inlined after elaboration.

The one new problem here is that let can be used in constant
expressions required for elaboration. Clearly hierarchical references
to let expressions can not be permitted in constant expressions.
 

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of Gordon Vreugdenhil
> Sent: Wednesday, June 06, 2007 3:16 PM
> To: sv-ac@eda.org
> Cc: sv-bc@eda.org; sv-ec@eda.org
> Subject: [sv-bc] Re: [sv-ec] Updated proposal for 'let' syntax
> 
> 
> Points 5, 6, and 7 appear contradictory.
> 
>    5)  ... In the scope of declaration, let must be defined 
> before used.
>    6) The let expression is inlined ....
>    7) The let expression can be referenced by hierarchical name...
> 
> Given:
>     module top;
>        int x = some_non_existent_module.some_let_name;
>     endmodule
> 
> How does one inline the let expression in the presence of 
> separate compilation?  Clearly one cannot.
> 
> Any statement of "inlining" is incomplete and not possible in 
> a general Verilog design.  Any requirements for inlining in 
> the presence of hierarchical names are in conflict with the 
> rest of the LRM semantics and must be struck or be 
> well-defined in terms of the **elaboration** model.
> 
> (5) also directly conflicts with (7).  If (7) is true, then 
> the following is legal:
>     module top;
>        int x = top.y;
>        let y = 0;
>     endmodule
> But (5) just claimed that you cannot refer to the let before using it.
> 
> 
> 
> The typing of "let" in hierarchical contexts is not defined.
> For example,
>     module M;
>        let f(x,y) = { x, y };
>     endmodule
> 
>     module top;
>        int q[$];
>        bit a, b;
>        bit[1:0] c;
>        initial begin q.push_back(1); q = M.f(q, 1); end
>        initial begin c = M.f(a, b); end
>     endmodule
> 
> 
> Is "M.f" really supposed to represent queue push in one call 
> context and bit concatenation in the other?
> Do people really want to have this be a requirement in the 
> face of separate compilation?
> 
> 
> The proposal doesn't give the grammar changes for where a 
> let_declaration is legal.  Is it legal in a class?
> If so then under what circumstances is a "let" static?
> Given an intentionally incomplete definition:
>     class C;
> ...
>       let something = something_else;
> ...
>     endclass
>     C c = new;
> 
> Under what conditions is "C::something" valid?  What about 
> "c.something"?
> 
> 
> 
> Given:
>       let f(x,y) = x + y;
> Is it (supposed to be) true in all circumstances (including 
> all context-determined circumstances) that 
> "<some_hierarchical_path>.f(a,b)" can substitute for "a + b" 
> without any change in the results of the overall expression?
> 
> I simply do not buy the suggestion that has been made that 
> "let" can both act like a function and act like a macro.  I 
> don't have any problem with having let be a "macro" like 
> construct in packages where you are guaranteed to have 
> visibility to the let body PRIOR to use.  That was, I 
> thought, what the key requirements were.  Unfortunately, this 
> has become seriously entangled in other constructs where the 
> interactions are not nearly that simple.
> 
> The performance implications of implementing this (not to 
> mention the semantics) for general cases makes me quite 
> opposed to the generality of this proposal.
> 
> Gord.
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
> 
> -- 
> 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.