RE: [sv-bc] Package and identifier "::" rules

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. 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.

-----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

-- This message has been scanned for viruses anddangerous content by MailScanner, and isbelieved to be clean.