RE: [sv-bc] Resolving name resolution

Thanks, Gord.  Then let's resolve the philosophy first.  For the reasons
in

    http://www.eda-stds.org/sv-bc/hm/6429.html

don't we generally have to wait until elaboration?  For example, a local
type could be a redeclaration of a type from a parameterized interface

    module mod(IFC ifc, ...);
      typedef ifc.T T;
      ...
    endmodule

so the name resolution algorithm must be able to take that into account.


-- Brad

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Thursday, August 30, 2007 1:11 PM
To: Brad Pierce
Cc: sv-bc
Subject: Re: [sv-bc] Resolving name resolution


Brad Pierce wrote:
> Gord and Mark,
> 
> What are the key differences between your two approaches to name 
> resolution?

That isn't easy to answer but I'll take a shot.  Mark can obviously
correct me or provide his interpretation too.

Note that in the following when I use "interfaces" I mean that in a
generic manner unless I say "SV interfaces" in which case I mean the SV
design unit.


The biggest issue is, I think, a philosophical one, but one that has
fairly deep ramifications.

In Verilog, even in the presence of hierarchical names, it was possible
to determine by local inspection whether a name bound locally or not.
If it didn't the special hierarchical name rules kicked in.  So a
designer always explicitly knew when they had "topological" or non-local
dependencies in their design.  They could code locally with a high
degree of certainty as to the meaning of simple names and when names
depended on design-wide assumptions.

SystemVerilog muddied the waters along many fronts -- the overloading of
"dotted names" to mean BOTH hierarchical names and structure/class
selection, the introduction of classes and inheritance, type parameters,
package imports, bind, SV interface ports, compilation units, and
implicit dotted name "methods" on arrays have all contributed to
complicate the name resolution and, in some cases, change traditional
Verilog semantics (array methods are really nasty here).

So, what to do?

Mark's suggestion is to make many more things dynamic.  "When in doubt,
defer to elaboration" would be a gross over-generalization of Mark's
position, but one that I don't think is entirely unfair.

I don't think that position serves the design community, the
implementors, or the future of the language very well.

It is far easier to reason about modular design composition, language
feature interaction, etc. in the presence of much more local semantic
guarantees.  My approach is to hold to the designer's original ability
to reason locally about names.  Clearly a designer needs to know about
package interfaces, etc. in order to reason locally, but I really
believe that it is critically important to the future of SV to keep to
as strong a line as possible on that front.

This is why I am so strongly opposed to the highly dynamic name
resolution effects and late errors that Mark is proposing.  I don't
think we are very far off from being able to have a much stronger and
more compositional model that preserves one's traditional ability to be
able to reason explicitly about when non-local interactions are in play.
Sacrificing that carries a very, very high price that everyone in the
community is going to be paying for a very long time.

So, that is my take (obviously biased!) on the positions.

Then there are a bunch of other differences, some of which are related,
some of which aren't.  A few are:
   1) what names are visible to a "bind"?
   2) are class members/methods visible in a forward
      manner?  Consistency of name interpretation is a big
      issue here and I've raised some of that already.
   3) $unit forward visibility


Most of those are likely resolvable once the philosophical approach is
settled.

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.