Mark Hartoog wrote: > When we discussed this I thought we decided that if a class and package of > the same name were visible, we would always bind to the class. Yes; our recollections of that are the same. > Since we have > extended '::' operator to apply to typedefs and type parameters, I think we > should bind to them like we bind to classes, since the typedef or type parameter > must resolve to a class to be legal. I think that falls into what I was suggesting -- and in particular that for my first example in 3 that the example should be illegal even though the name "C" is known at compile to not admit "::". Gord. > > -----Original Message----- > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Gordon Vreugdenhil > Sent: Monday, December 08, 2008 9:16 AM > To: SV_EC List; SV_BC List > Subject: [sv-bc] Package and identifier "::" rules > > > Package names are part of the package name space in SV (3.13). > The exact implications of that are not described very clearly. > > It is clear that you can have a module and a package of the same > name (although I think that was a mistake to allow in the language). > However, if there is a visible name that does/doesn't > admit "::", how does that interact with the package referencing > and the "different namespace"? > > > Here are a few examples: > > 1) > package C; > int x; > endpackage > module top; > class C; > static int x; > endclass > initial $display(C::x); > endmodule > > > Comments: legal; C::x binds to the class since that is "closer". > I think there was consensus on this although I don't think this > made it into specific LRM text > > 2) > package C; > int x; > endpackage > module top; > class C; > static int y; > endclass > initial $display(C::x); > endmodule > > Comments: Is this an error? I think it should be. The class > "C" admits "::" and it would be far to easy to have unintended > name capture in non-trivial situations if C::x would continue > searching in the package name space once "C" was resolved. > > > 3) > package C; > int x; > endpackage > module top; > typedef int C; > initial $display(C::x); > endmodule > > Comments: I'd like to claim that this is illegal since the > closest visible "C" doesn't admit "::". > > This becomes a stronger argument if we have: > > package C; > int x; > endpackage > > .... > > module child #(type C); > initial $display(C::x); > endmodule > > If we have a rule that says that non-class prefix types are > "ignored", then C::x can't be resolved until elaboration > time and will require elab time package resolution. If we > have the simpler rule that the "closest" name wins, then > elab will either succeed or fail based on the actual type of > the parameter, but there will not be a late attempt to resolve > into the package. > > I think that it is far better to have the "closest" rule where > a package name prefix would only be considered after $unit. > I think this would be the least surprising since users > would just consider the closest prefix name rather than all > of the possible names. Being able to reason more locally > about the names tends to be less surprising to users. > > 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. > > > -- > This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com -- -------------------------------------------------------------------- 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 Mon Dec 8 14:24:51 2008
This archive was generated by hypermail 2.1.8 : Mon Dec 08 2008 - 14:28:59 PST