RE: ISAC: D3.0 question uncovered while examining IR2099

From: Peter Ashenden <peter_at_.....>
Date: Fri Mar 16 2007 - 22:51:56 PDT
Chuck,

I think you're right that the potentially visible explicit declaration would
become directly visible. It's not clear that it actually hides the label,
since there is no definition for a potentially visible declaration made
directly visible to hide any other directly visible declaration. The Note at
the end of 10.4 seems to suggest that the rules preclude the possibility,
but should they not have done so, such hiding would have occurred.

Note that even if the label were hidden by the used declaration, you could
still use an expanded name to refer to the label, although that would look
unfamiliar to most people.

There is the issue of backward compatibility. Suppose we have the following

  package p is
    type T is ...
  end package p;

  architecture a of e is
    use work.p.T;
    attribute x : string;
    attribute x of T : label is ...
  begin
    T : block is ...
  end architecture a;

Under the old rules, this would be legal. The potentially visible work.p.T
would not be made directly visible, given the implicitly declared label T.
Under the new rules as written, work.p.T would be made directly visible. If
it is deemed to hide the label, the attribute specification would be
illegal. That was probably not intended. If both the used declaration and
the label are directly visible, then the reference to T in the attribute
specification would be ambiguous, since the rules in 10.5 for overload
resolution of names don't include taking account of the entity class of a
name. Again, the model would be illegal.


This does, of course, beg the question of whether a label is actually a
declaration. I think the intention is that it be treated as such, though it
is not listed as a declaration in Clause 4. If it is not a declaration, then
it has no scope, cannot be visible, and cannot be a homograph!

This one one of several cases of declarations that aren't covered by the
syntax rule of Clause 4, some others being enumeration literals, physical
units, and record elements. Perhaps we need to clarify Clause 4 by
specifying that the syntax rule for declaration is not exclusive, and that
enumeration declarations, physical unit declarations and label declarations
are declarations also. Then the rules of Clause 10 would clearly apply to
these declarations, as intended.


Returning to 10.4: Now that I revisit it, it looks like the wording is
problematic, and does not accurately capture the intent of FT-1 (the
requirement from which the LCS was derived).

In the list on page 231 of D3.0, item a) is intended to give potentially
visible implicit declarations lower priority than used explicit declarations
of homographs. However, the wording is "if the place considered is within
the scope of an explicitly declared homograph of that implicit declaration."
That doesn't cover a potentially visible explicit declaration, since the
scope of the declaration doesn't extend to the places that are the scope of
a use clause identifying the declaration. To illustrate:

  package p1 is
    type T is 0 to 10;
    -- implicit declaration of "<"
  end package p1;

  package p2 is
    function "<"(L, R : T) return boolean;
  end package p2;

  architecture a of e is
    use work.p1.all; use work.p2.all;
    -- ** This place is in the scope of the use clauses,
    --    but not in the scope of work.p2."<",
    --    so both work.p1."<" and work.p2."<" are directly visible.
  begin
  end architecture a;

List item c) also applies here, since both potentially visible declarations
at ** have the same designator and are subprograms. So a reference to "<" at
** would be ambiguous, since both work.p1."<" and work.p2."<" would be
directly visible.

Let's fix this by rewriting a) as:

  a) A potentially visible implicit declaration is not made directly visible
     if the place considered is within the scope of a use clause that
     identifies an explicitly declared homograph of that implicit
declaration.

I've also dropped "of a predefined operation" after "implicit declaration" -
this would need to be checked against the IR2099 proposed wording dealing
with alias declarations.

Item b) gives a used explicit declaration lower priority than an explicit
homograph in the using region. This is where implicitly declared homographs
were overlooked, presumably because we didn't think they could occur. So
let's just make it any homograph, whether explicitly or implicitly declared.
Moreover, why does this only apply to potentially visible explicit
declarations, and not potentially visible implicit declarations? For
example, if a package implicitly declares MINIMUM, and I use it in a region
that declares (explictly, or implicitly as a label) MINIMUM, then the used
name should have lower priority than the local name. Thus we can rewrite b)
as:

  b) A potentially visible declaration is not made directly visible if the
     place considered is within the immediate scope of a homograph of
     the declaration.

Which is back to what we had in VHDL-2002! So what have I missed in this
circuitous trip?

Finally, item c). The double negative specifies that two potentially visible
declarations that are subprograms or enumeration literals are made directly
visible, without mention of whether they are homographs or not. If both are
explicitly declared and not homographs of something in the using region,
then neither a) nor b) applies, so c) makes them both directly visible. I
presume that this long-standing rule is what people refer to when they say
you can't use homographs from different packages. The common wisdom is that
neither becomes directly visible. But it would seem more accurate to say
that both become directly visible, and thus a reference to them is
ambiguous. If that understanding is correct, would it be clearer to add to
the end of c) something like "and they are not homographs"?

Sorry about the long-winded and circuitous analysis. Hopefully we can glean
something useful out of this.

Cheers,

PA
--
Dr. Peter J. Ashenden         peter@ashenden.com.au
Ashenden Designs Pty. Ltd.    www.ashenden.com.au
PO Box 640                    VoIP: sip://0871270078@sip.internode.on.net
Stirling, SA 5152             Phone (mobile):  +61 414 70 9106
Australia


> -----Original Message-----
> From: owner-isac@server.eda.org 
> [mailto:owner-isac@server.eda.org] On Behalf Of Chuck Swart
> Sent: Saturday, 17 March 2007 11:13 AM
> To: isac@server.eda.org; john ries
> Subject: ISAC: D3.0 question uncovered while examining IR2099
> 
> 
> LRM version D3.0 contains in Clause 10.4 Use clauses:
> 
> "A potentially visible declaration is actually made directly visible 
> except in the following three cases:
> ...
> b) A potentially visible explicit declaration is not made directly 
> visible if the place considered is within the
> immediate scope of an explicitly declared homograph of the 
> declaration."
> 
> Isn't there a problem with this rule? Specifically, A label is 
> implicitly declared and is a homograph of
> any other declaration with the same name. So, under the new 
> wording, a 
> use clause would make directly
> visible a potentially visible declaration with the same name as the 
> label. Wouldn't this make the label
> no longer visible?
> 
> Any ideas?
> 
> Chuck Swart
> 
> 
> 
> -- 
> 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.
Received on Fri Mar 16 22:52:20 2007

This archive was generated by hypermail 2.1.8 : Fri Mar 16 2007 - 22:52:21 PDT