RE: [sv-bc] name resolution (some rules for consideration)

I have a few comments on this.

> 1. When a scope is finished its compilation, it is closed - 
> no more symbol
>     introduction.  The only exception is that an elaboration 
> time "bind"
>     can introduce additional instance names and implicit net 
> names into
>     the target scope.

Clearly generate can also introduce new names into a scope also. 

> 2. within a method, an identifier reference is resolved by 
> doing searches
>     in the following order:
>        1. bind into the local scope (upwards to the method 
> declaration)
>        1. bind into the local class
>        2. bind to any inherited names
>        3. bind following normal lexical/import/hierarchy 
> rules in the parent
>           scope of the local class decl

The question is when can you do this. If the base class can be
a forward typedef or a type parameter, you cannot do this until
elaboration.

> 5) in a dotted name, if the first/next name binds to a 
> declaration that MAY
>     permit a dot select , no backtracking occurs.

This seems very unclear to me. When is this rule applied? When
the dotted name is first parsed? Or at elaboration? At elaboration
time you should know what the value of the type parameters 
are, so I'm guessing you are proposing to do this at parse time,
which I think is an unworkable idea.

> 6) In a hierarchical name, once a "bit select" is matched to 
> a scope that permits
>     a bit select, no backtracking
> 
>     This means that once you've matched, for example, an 
> arrayed generate name
>     or an arrayed instance, you never backtrack upwards.

Why? Why do you allow any backtracking and forbid this backtracking?

> 7) all class members are visible to the body of extern methods

This statement sounds fine, but the example after implies much more
than this rule, and I disagree with the second example.



> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of Gordon Vreugdenhil
>
> 1. When a scope is finished its compilation, it is closed - 
> no more symbol
>     introduction.  The only exception is that an elaboration 
> time "bind"
>     can introduce additional instance names and implicit net 
> names into
>     the target scope.
> 
>     Implication -- external references, extern tasks, etc. 
> cannot introduce
>     new names.  The set of imported names is known when the 
> "end" of the
>     scope is encountered.
> 
> 
> 2. within a method, an identifier reference is resolved by 
> doing searches
>     in the following order:
>        1. bind into the local scope (upwards to the method 
> declaration)
>        1. bind into the local class
>        2. bind to any inherited names
>        3. bind following normal lexical/import/hierarchy 
> rules in the parent
>           scope of the local class decl
> 
> 3) for a package or class prefix, if a matching class name is 
> visible, the
>     class is the context, the package is last.
> 
>     Example:
> 
>         package C;
>            int x;
>         endpackage
>         class C;
>            static int x;
>         endclass
>         module top;
>            int y = C::x;   // binds to visible class C not package C
>         endmodule
> 
> 4) package or class prefix names never back tracks in search
>     (i.e. once you have matched a "<name>::" prefix, you will never
>      back up and try again)
> 
>     Example:
> 
>         package C;
>            int y;
>         endpackage
>         class C;
>            static int x;
>         endclass
>         module top;
>            int z= C::y;   // error -- "y" doesn't exist in class C
>         endmodule
> 
> 
> 
> 5) in a dotted name, if the first/next name binds to a 
> declaration that MAY
>     permit a dot select , no backtracking occurs.
> 
>     The "may" here is important.  The basic rationale of 
> Steven and I is that
>     we'd like to get rid of backtracking in the resolution 
> other than in
>     cases that are required for legacy support.
> 
>     The following is a legacy example:
> 
>        module top;
>          integer x;
>          child c();
>        endmodule
>        module child;
>          integer top;
>          initial top.x = 5;  // resolves to $root.top.x
>        endmodule
> 
>      The following is a problematic case:
> 
>        module top;
>          integer x;
>          child c();
>        endmodule
> 
>        module child #(type parameter T = int);
>          T top;
>          initial top.x = 5;    // error at elab since "top.x" 
> is required to
>                                // resolve into "T top"; is 
> "T" is not a structure
>                                // type with an "x" this 
> becomes an elab error
>        endmodule
> 
> 
> 6) In a hierarchical name, once a "bit select" is matched to 
> a scope that permits
>     a bit select, no backtracking
> 
>     This means that once you've matched, for example, an 
> arrayed generate name
>     or an arrayed instance, you never backtrack upwards.
> 
> 
> 
> 7) all class members are visible to the body of extern methods
> 
> 
>      Example:
> 
>          class C;
>            extern task foo;
>            int x;
>          endclass
> 
>          int x;
>          extern task C::foo;
>              x = 1;   // means this.x = 1
>          end
> 
> 
>      Implication:
> 
>          package p;
>             int x;
>          endpackage
> 
>          import p::*;
> 
>          class C;
>            task foo;
>                x = 1;   // means p::x
>            end
>            int x;
>          endclass
> 
> 
> 8) An extern class method with a reference to an identifier 
> that resolves
>     outside the method (including other class members) shall 
> resolve the
>     identifier based on the point of declaration of the extern method.
> 
>     Example:
> 
>          package p;
>             int x;
>          endpackage
> 
>          import p::*;
> 
>          class C;
>            extern task foo;
>          endclass
> 
>          int x;
>          extern task C::foo;
>              x = 1;   // means $unit.x and not p::x
>          end
> 
> 
>      This is related to rule (1).  If one would want to treat 
> the "x = 1"
>      reference as p::x then you have to "go back" and determine that
>      the "int x" declaration is an illegal conflict.  There should be
>      no "going back" requirement.
> 
> 
> --
> --------------------------------------------------------------------
> 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 message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.