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