Comments on IR2099

Folks,

My guilt level has risen sufficiently high that I'm now looking over IR2099.

In the Analysis, Principle 1 states that an alias of a declaration is not a
homogaph of the declaration, and two aliases that denote the same named
entity are not homographs of each other. However, this does not appear to be
completely captured in the recommendations for future revisions.

The recommendations include adding an exception to the wording starting "If
overloading is allowed for both declarations...". That covers aliases
denoting enumeration literals and subprograms. I think we overlooked the
preceding sentence dealing with aliases of non-overloadable items, such as
types and subtypes:

  Each of two declarations is said to be a homograph of the other if both
  declarations have the same identifier, operator symbol, or character
literal,
  and if overloading is allowed for at most one of the two.

I think we need to change the pair of sentences to something like:

  Each of two declarations is said to be a homograph of the other if and
only
  if both declarations have the same identifier, operator symbol, or
character
  literal; and they denote different named entities; and either overloading
is
  allowed for at most one of the two, or overloading is allowed for both
  declarations and they have the same parameter and result type profile (see
  3.1.1).

Regarding Example 1b - a minor correction that does not affect the
technicalities of the analysis: The alias declaration introduces an implicit
alias declaration for "="[my_logic, my_logic return boolean]. The signature
is not [alt_logic, alt_logic return boolean] as stated. Thus, the alias has
exactly the same signature (using the aliased type name, not the alias type
name). Either way, it's still no longer a homograph.

Regarding Example 5a: The analysis states that the VHDL-2006/D3.0 rules make
a potentially visible explicit declaration hide an otherwise visible
implicit declaration. However, that does not appear to be clearly stated in
D3.0. It specifies that the potentially visible explicit declaration in this
example is made directly visible, since none of case a), b) or c) in 10.4
apply. However, 10.3 doesn't fill in the gap of hiding the implicit
declaration. It only deals with an explicit declaration hiding an implicit
declaration when both occur immediately within the same declarative region.
I think that is a deficiency in the VHDL-2006 specification that should be
remedied - maybe as part of #131. So in IR2099's analysis, we should
probably state that the intent in D3.0 was to give the potentially visible
explicit declaration priority over the implicit alias, but that that needs
to be correctly implemented by the LRM-SC.

Regarding Example 10b: Again, the D3.0 rules aren't precise, making this
case unclear. The intent in D3.0 was that if an explicit declaration and an
implicit declaration that are homographs are both made potentially visible,
then the explicit declaration gets priority. However, the wording in D3.0
expresses this in terms of visibility of the potentially visible implicit
declaration within the scope of the explicitly declared homograph. It should
probably refer to the scope of a use clause that makes the explicitly
declared homograph potentially visible. Again, this should be fixed by the
LRM-SC.

Regarding Example 10c: The assumption is that two potentially visible
explicitly declared homographs are not made directly visible. However, the
longstanding wording covering this is not clear, as I outline in my comments
in #131. Again, the LRM-SC should address that as part of the cleanup in
10.4.

In summary, I think we need to fix the recommended wording change for 10.3.
My other comments relate to changes addressed in VHDL-2007, which the LRM-SC
needs to review as part of #131. They do not affect IR2099, since we
understand the intent.

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: +61 8 7127 0078
Australia                     Mobile: +61 414 70 9106


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