[sv-ec] Name resolution for bind -- AC feedback requested

This note raises some name resolution questions in the
context of "bind".  The issues were discussed on Monday's meeting
with no consensus but no huge disagreements either -- we
just need to decide and clarify some of the text.



The name resolution group would request that AC review the
following and provide feedback immediately as clarifications
need to be made by EC before its deadline.




There are bits of somewhat contradictory wording in the LRM that
lead one to different conclusions in terms of what a bind
statement can refer to in the context of the target.

The bits of wording in 22.10 that are confusing are:

     No semantic changes to the assertions are introduced due to
     this feature. It is equivalent to writing properties external
     to a module, using hierarchical path names.

and

     When an instance is bound into a target scope, the effect will
     be as if the instance was present at the very end of the target
     scope. In other words, all declarations present in the target
     scope are visible to the bound instance.


The basic questions are as follows:
   1) can a bind reference all visible names (including wild-card
      imports) of the target
   2) can a bind reference compilation unit items from the
      bind target context
   3) can a bind reference types in the target context


Arturo believes that the original intent was that the names
referenced by the bind must actually be declared in that context.
Ignoring types, this roughly boils down to names that could be the
target of some hierarchical reference.  This is supported by
the first of the quoted statements above and is also what
my (Gord's) expectation was.


Mark H. wanted to make sure that everyone was Ok with that interpretation
as it is somewhat contradictory with the "very end of the target" rule
which could be read as allowing reference to imports (including only
potential imports via a wildcard) and references to the compilation unit.


There are various issues that arise if one does not restrict the
visibility to the "declared" items.  In particular, if one binds
into a nested module, having a new reference to a name could
cause problems due to bringing a new name into a scope via an
import.  This could cause a bind to *create* an error in the
target module.  We don't think that would be good behavior.



On the type reference issue, both Mark H. and I believe that
there are basic parsing issues that arise in terms of type
management.  We agree (I think) that types and explicit package
references must be parsed in the context of the bind statement,
not the context of the bind target.  This means that if a bind
needs to explicitly reference types shared with the target instance,
such types would need to live in a package and be reference
explicitly in the bind statement.  We do not think that this
compromises the intent or functionality of bind.


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.