Re: [sv-bc] FW: wildcard import name resolution

Gordon & Françiose,

  I would like to amend your proposal to use protocol #1 (below)
instead of protocol #2 when resolving a name in a function call
context.  Since you must look everywhere in the current scope for
function declarations, you might as well also look everywhere
in that scope for wildcard import candidates too.  Is there a
Mantis # assigned to your proposed change?

  I assume "function call context" is well enough defined and
syntactically unique.  Gord, what did you mean when you suggested
there was an interaction with 2217 dotted name rules?

Greg

Greg Jaxon wrote:

> The point I find most difficult in Françiose's algorithm is when
> the function call does not match a declaration in the /most local/ scope.
> The search has three choices worth consideration:
>   1 - triggering any and all wildcard bindings of the name in the most
>       local scope
>   2 - triggering just the local wildcard bindings that were visible lexically prior
>       to the first use.
>   3 - looking up-scope to a surrounding declaration.
> 
> I rule out 3 immediately because it won't match the way wire names are bound.
> 
> 2 is problematic because it invokes a past state of the lexical scan.
> It also clouds one of the principles we just invoked:
> 
>   package pkg1;
>      task t; endtask
>   endpackage
>   package pkg2;
>      task t; endtask
>   endpackage
>   module m;
>      import pkg1::*;
>      if (1) begin:b
>         initial t();             // pkg2::t
>         import pkg2::t;
>      end
>   endmodule
> 
> Presumably, an explicit import is as good as a declaration.
> Yet if we only wildcard import from pkg2, it seems bad to
> switch to pkg1 without any collision.   Better to have been
> using pkg1::t all along?  That suits a context-insensitive
> lexical level of wildcard name resolution.
> 
> If not, then maybe it is better to resolve function/task calls
> LATE  (#1 above) and do it in the final binding context for the scope
> where the collision I set up would be detected.
> 
> This version would suit our implementation a little better, and
> I think it dovetails with hierarchical resolution rules more naturally,
> since they are not possible until all scopes have finished parsing.
> 
> Greg




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