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. 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. 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 > > > -- -------------------------------------------------------------------- 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.Received on Tue Dec 18 13:22:15 2007
This archive was generated by hypermail 2.1.8 : Tue Dec 18 2007 - 13:22:30 PST