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