[sv-bc] Re: [sv-ec] $unit and function resolution

Bresticker, Shalom wrote:
> Gord,
> 
> In 3.10.1, what does the addition of "if the identifier follows
> hierarchical name resolution rules" exclude?

This is a pure correction.  An identifier is subject to instance
tree resolution unless it is a hierarchical name or a task/function
name.

> Regarding "Other than for task and function names (see 22.7.1),
> references shall only be made to names already defined in the
> compilation unit. The use of an explicit $unit:: prefix only provides
> for name disambiguation and does not add the ability to refer to later
> compilation unit items," this is a little ambiguous as to whether a
> $unit:: prefix can refer to later compilation unit items when those
> items are tasks and functions.

It wasn't my intent to restrict explicit $unit prefixing to already visible
tasks and functions.  The "doesn't add" was intended to apply to only
the normal names.

How about:
     The use of an explicit $unit:: prefix only provides
     for name disambiguation and does not impact the legality of references
     to later compilation unit items,


> The additions to 13.7 and 22.7.1 can be interpreted as implying that the
> forward referenceability of tasks and functions comes from special
> rules. Yet Steven Sharp and others in the past have said that this
> actually is a side-effect of the existing rules.

I was one of those arguing that point as well.

The existing rules can be read in a manner that the upwards resolution
was legal.  Since that matched existing practice, of course that is
the way in which vendors chose to read things.  The special interpretation
aspect was related to the upwards rules where a "scope_name.item_name"
was allowed to be just a "scope_name" and thus all tasks and functions
(which are scopes) to resolve in an upwards manner.

However, I found that I needed to treat $unit in a different
manner since it does NOT participate in the full upwards rules.
As a result it was easier to explicitly break out the handling
of task and function names.  In 22.7.1 I directly appeal to the
hierarchical resolution rules and explain how the relationships
interact.  The 13.7 comment about the "modified" rules is only
to deal with the "look in the entire compilation unit scope"
rule before going up the instance tree.  That is really the only
*behavior* modification in the proposal.

I did specifically put quotes around the word "forward" in the
13.7 sentence (This means that “forward” references...) to specifically
address the way that users think about what is going on.


> Are the rules for properties and sequences the same as for tasks and
> functions? This was discussed in the past as they also have forward
> referenceability. If they are the same, then 22.7.1 should say so. I
> don't remember whether SV-AC has passed some change in Clause 16 saying
> so.


We talked about this briefly in the name resolution meeting.  Rather
than try to dig out all task/function refs and determine if they
needed to be touched, we elected to leave this as just task/function
text.  The AC sections say that sequences and props resolve in the
same manner as functions so I think that all the rules do apply.

The AC has additional time to consider these changes so if they
don't agree, they can suggest additional changes to address
any concerns that they have.

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.