RE: [sv-bc] Name resolution - questions and issues review

Gord,

Re item (3), do references to properties and sequences use the same
rules as references to tasks and sequences? The LRM says that 'forward'
references work. Beyond that, it is not clear. If they are like tasks
and functions, then a non-dotted reference would find them in an upwards
hierarchical scope, for example.

Thanks,
Shalom

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gordon Vreugdenhil
> Sent: Thursday, September 20, 2007 7:34 PM
> To: SV_BC List; SV_EC List
> Subject: [sv-bc] Name resolution - questions and issues review
> 
> All,
> 
> Francoise asked for a summary of some of the name resolution 
> issues.  I don't want to try to capture all of the issues 
> here since at least the very contentious issues were 
> discussed exhaustively on the reflector.
> 
> Here are some of the more basic issues that need clarification:
>    1) how "static" is :: ?   Can you have "::" on a forward type?
>    2) how package like is $unit?  Are later declarations visible?
>       Is it even possible (as with a hierarchical reference in
>       a module) to create a forward reference?
>    3) we need to agree on a statement regarding "declaration before
>       use" to make things more explicit and explain exactly how
>       exceptions (functions, etc) work.
>    4) when does a dotted name become a select versus a hierarchical
>       name?  Can you forward reference a struct variable member
>       just because the reference contains a dot?
>    5) Is a clocking blocks a scope?  If so, does that imply that all
>       "cb.a" forms are inherently hierarchical and always bind using
>       the hierarchical resolution rules?
>    6) we need to discuss forward visibility in non-opaque classes
>    7) management of $unit and package lookup during hierarchical
>       name resolution
>    8) handling of package imports for bind
>    9) basic discussion of issues related to modports
> 
> There are certainly more issues here, but the above is 
> probably a fair sampling of issues for which the LRM should 
> be much more clear.
> 
> 
> Here are some links to relevant reflector discussion between 
> Mark and I:
>     () Gord's  very early (incomplete, etc) algorithm for
>        basic resolution in June, 2006:
>            http://www.eda-stds.org/sv-bc/hm/4623.html
>     () a later form of Gord's basic approach in more of a rule form
>            http://www.eda-stds.org/sv-ec/hm/4346.html
>     () Mark's basic approach to name resolution
>            http://www.eda-stds.org/sv-bc/hm/6472.html
>     () a summary related to how type parameters interact
>            http://www.eda-stds.org/sv-bc/hm/6567.html
>     () a summary of some of the issues related to type referencing
>            http://www.eda-stds.org/sv-bc/hm/6667.html
> 
> There are many other issues and examples floating about.  
> Here are a few that Mark and I have raised very early on.  
> I'd have to re-evaluate where we both are on all of these.
>       http://www.eda-stds.org/sv-bc/hm/6017.html
>       http://www.eda-stds.org/sv-bc/hm/6029.html
> 
> 
> I am working on a powerpoint agenda for Monday and am 
> planning on including the 9 basic issues above as well as a 
> shorter summary of the long back-and-forth that Mark and I have had.
> 
> If anyone has substantial questions that don't appear to be 
> covered in 1-9, please let me know and I'll add them to my 
> questions and issues list.
> 
> 
> 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.
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.