Re: [sv-bc] Root cause --- $unit is as broken as could be -- maybe too late to standardize it?

Gordon Vreugdenhil wrote:
> Stu,
> 
> It is not possible to treat $unit visibility in a manner that is identical
> to a normal package import.  The reason is that a package must exist
> *in its entirety* at the time that an import of that package occurs.

I agree.

> I would emphatically agree with the "import" approach but *only* if
> we agreed that $unit is really a "segmented" compilation unit and that
> other design units only got to "import" the names defined in the part of
> $unit that preceded that design unit.

$Unit should _not_ be wildcard imported into the modules and interfaces
it may contain!  Doing this will cause other "explicit" wildcard imports
from better defined packages to be blocked by the random cruft that might
appear outside the module's declaration.  This is the same complaint I make
about the implicit wildcarding of the "std" package - for which I still
think the LRM needs a lower priority of wildcard importation.  I believe
nested scope access to $unit is more than adequate!

> 
> For example:
>    typedef int T;
>    module foo;    // only gets to see "T"
>       T x;
>    endmodule
> 
>    typedef int T2;
>    module foo2;   // gets to see T and T2
>       T x;
>       T2 y;
>    endmodule
> 
> I think I've suggested this before (long, long ago in a universe
> far, far away).

I agree with this version of the segmented $unit concept.
Any version where the $unit scope is reset between modules would be wrong...

Notice that, in this form of segmenting, although foo cannot refer
directly to T2, nor access it by $unit::T2, he might still receive a
type parameter bound to $unit::T2.  If for example, T2 is a struct with a field
of type T1, foo will recognize that that field's type matches his $unit::T1.
In other words, foo has to recognize that the scope he calls $unit might
have things in it for which he has no known name binding.

> 
> You can describe this model by using import and export (or pretty
> closely using multiple imports):
> 
>    package $unit_part_1;
>       typedef int T;
>    endpackage
> 
>    module foo;
>       import $unit_part_1::*;
>       T x;
>    endmodule
> 
>    package $unit_part_2;
>       export $unit_part_2::T;
>       typedef int T2;
>    endpackage

BAH! Your $unit_part_2 needs to import & re-export all of $unit_part_1.
Probably you've got a typo above.
It will need things from $unit_part_1 to declare its functions and structs.
> 
>    module foo2;   // gets to see T and T2
>       import $unit_part_2::*;
>       T x;
>       T2 y;
>    endmodule

But this is still a broken model.  What if the original code was:
  package malicious;
     typedef enum{ ZERO } T;
  endpackage
  module foo2;   // shadows T, but uses T2
     import malicious::*;
     T x;
     T2 y;
  endmodule

Gord's segmenting idea describes the only technique I know for this
that is consistent with LALR(1) one-pass parsing.  Requiring implementers
to use more sophisticated scanners, also requires SV users to scan
more code using a more sophisticated mental model of how it will be
parsed.

Greg


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.