Re: [sv-bc] Task function identifier searching rule

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Mon Jan 12 2009 - 07:07:01 PST
Shalom,

Unfortunately some of the rules are still scattered a bit.  It
is crucial to look at 26.3 (draft 8) first since that discusses
the impact of imports.  In part it has:

    For a reference to an identifier other than function or
    task call, the locally visible identifiers defined at the
    point of the reference in the current scope shall be
    searched. If the reference is a function or task call, all of
    the locally visible identifiers to the end of the current
    scope shall be searched. If a match is found the reference
    shall be bound to that locally visible identifier.

The last bit (effectively the forward references) are implied in 23.8.1
by the fact that the 23.8.1 step is assumed to be an elaboration step
when all the scope names are present and it really only deals with
the names that have NOT been bound by the "earlier" import binding
as described in 26.3.


Part of the issue in this space has always been that "forward"
references really aren't "forward" references; they are simply
references that follow the later "elaboration time" resolution
when ordering within a scope is no longer material.  The entire
discussion about "forward referencing" is a nod to how users
like to think about the resolution but isn't really how an
implementation does the resolution.  That is also the reason
that task/function names (even though they are not dotted) will
also resolve in an upwards manner in the actual instance tree
while a normal identifier will not. Much of the convolution
in the rules is to maximize legacy compatibility and minimize
"surprising" results of the new rules.  The resulting rule set
is pretty complex and there are edge cases that still have some
amount of surprise, but that's life.

Gord.


Bresticker, Shalom wrote:
> Hi, I agree with the comments of all the committee members.
>  
> However, I am a little confused about where the forward referencability 
> of subroutines is described in the LRM.
>  
> I thought Mantis 1809 was supposed to document this, and I myself was 
> reasonably satisfied when I reviewed the proposal. But I don't see it now.
>  
> 1809 added section 13.7, which says,
> 
> "Task and function names are resolved following slightly different rules 
> than other references. Even when used as a simple name, a task or 
> function name follows a modified form of the upwards hierarchical name 
> resolution rules. This means that “forward” references to a task or 
> function defined later in the same or an enclosing scope can be 
> resolved. See 23.8.1 for the rules that govern task and function name 
> resolution."
> 
> So this implies that 23.8.1 should describe it. But the sentence there 
> that seems relevant to me is: "Then, before proceeding with step (b), an 
> implementation shall look in the complete compilation unit of the 
> reference."
> 
> That is fine where the subroutine is defined in the compilation unit 
> scope. But what about where the subroutine is declared in the same scope 
> as the forward reference?
> 
> Thanks,
> 
> Shalom
> 
> ---------------------------------------------------------------------
> 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* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
--------------------------------------------------------------------
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 Jan 12 07:16:43 2009

This archive was generated by hypermail 2.1.8 : Mon Jan 12 2009 - 07:17:49 PST