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

Gordon Vreugdenhil wrote:
> 
> Greg, I want to give a bit of perspective on what is going on here.
> 
> You said:
> 
>   This differs from the rules currently given in the LRM.  A function
>   name that is available as potentially locally visible in any of the
> enclosing
>   scopes is considered /before/ later declarations as a function in any
>   of those scopes.
> 
> That was part of the original entire discussion.
> 
> Let's go back to 1364-2005.
>   module m;
>      task t; endtask
>      if (1) begin:b
>         initial t();             // (A)
>         task t(); endtask
>      end
>   endmodule
> 
> Given the above, everyone agreed that at line (A) t would
> bind to m.b.t and NOT to the lexically preceding m.t
> 
> I assume that you agree with that as well.

Reluctantly, but it matches the facts of the matter.

> Given that, it seemed bad to have:
>   package pkg;
>      task t; endtask
>   endpackage
>   module m;
>      import pkg::*;
>      if (1) begin:b
>         initial t();             // (A)
>         task t(); endtask
>      end
>   endmodule
> 
> end up changing the binding of (A) to be pkg::t.

Especially if an explicit import pkg::t in place of the wildcard
would have still resulted in binding m.b.t().

> My solution (the original 1809 proposal) was to say that
> the reference at line (A) causes the import of t but does
> NOT necessarily bind to that import.  So at (A) we would bind
> t to m.b.t but the name  "t" would end up as an unreferenced
> import in scope m.  This could cause a conflict with another
> declaration of t later in m.
> 
> Francoise objected to having an *unused* imported name cause
> such a conflict.

I'm sorry, I missed that discussion thread.  Thanks for repeating
this line of reasoning.

> Her rules are designed to avoid that conflict.
> 
> My position is that I am not sure that avoiding the conflict
> is necessarily a good idea, particularly in the context of
> $unit.  In addition I am not sure that Francoise's rules
> correctly account for the 2217 rules for binding dotted
> names.
> 
> Gord.

It does seem like there are 2217 rules for binding dotted names ;-)

I have to sympathize with Françiose's idea that unused bindings
should not trigger wildcard import.  I would think $unit pollution
would argue in favor of her view, not against it.

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.