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

Gordon Vreugdenhil wrote:
> Greg,
> 
> I would definitely object to the protocol #1 approach.  That
> is both inconsistent with the 2005 LRM and with other forms
> of resolution.

> I can bring myself to have some special rules for tf resolution
> due to both compatibility to concerns and "expectation
> compatibility" but I will not agree to make invalid designs
> that work currently.

It's true that would happen if a colliding wildcard candidate
arrived after the first t/f use of a wildcard import.

> Although I have to still look at some issues, I currently
> think that Francoise's proposal is "stronger" in the sense
> that the eager approach will fail in some situations that
> Francoise's will not while the reverse is not true.  The
> approach you proposed is weaker -- some things will not
> resolve that would have before.  That is not acceptable to me.

I can sympathize with that analysis.
Does your proposal treat an explicit import of the function
name the way it would treat a task or function declaration?
I.e.: can a called name bind to an explicit import which
occurs after the first (function context) use?   This would
arise when the declaration moves into a package body.

Greg

> 
> Gord.
> 
> 
> Greg Jaxon wrote:
>> 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.