ISAC: [Fwd: Re: Vector concatenation issue] IR2126 reply from Tim McBrayer

Tim McBrayer issued the IR and has given permission for me to forward 
our emails discussing this issue.
this is his response to the email I just forwarded to the ISAC.
We can use my email and Tim's response to start our analysis.

Chuck Swart



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

attached mail follows:

Chuck,

Thanks for your very detailed response to my query.  To address your
last point first, I submitted this issue to ISAC yesterday evening, 11
Dec 2007, requesting clarification.  I believe that you are a member of
ISAC; please feel free to add your thoughts and analysis to the
submission, if that is acceptable under IEEE, DASC, VASG, and/or ISAC
procedures.  I'll be happy to work in whatever way possible with ISAC to
clarify this issue.  Let me stress that I am fundamentally looking for
clarification and perhaps disambiguation of the standard; this is most
certainly not about trying to have my viewpoint be interpreted as the
correct one.  I have no personal vesting in this other than trying to
understand what the VHDL LRM is truly specifying in this case, and
helping to clarify it if that is deemed necessary.

With all that being said, I would like to respond to your analysis.

I cannot really find fault with any of your references or reasoning,
other than perhaps they do not go far enough.  I believe that we are in
agreement, for example, on the intent of the type conversion.  Also,
while I did not directly reference the overload resolution rules in
Clause 10.5, I agree with most of your statements concerning that
clause, too.  You stated:

  "Our interpretation is that the rules of Clause 10.5 are applied
within
   the operand expression to determine the type of the expression, but
   that no information in the context outside of the expression is used
in
   this determination.  We believe that this is the only reasonable
   interpretation, otherwise, there are no criteria to determine which
   rules of 10.5 to apply. For example, 10.5 states "At such a place,
all
   visible declarations are considered."  If this rule doesn't apply,
then
   how do we decide which declarations are to be considered?"

This rule absolutely does apply; both &(element, element) return T and
&(T, T) return T are up for consideration here.  Both of these forms of
the concat operator are visible and may potentially apply in this case.
This potentiality is even explicitly called out in Note 2 at the end of
7.2.4:

  "Additionally, for a given concatenation, there may be visible array
   types that allow both case a) and case c) to apply.  The
concatenation
   is again ambiguous and therefore an error if the overload resolution
   rules cannot be used to determine a result type uniquely."

On the face of it, this note explicitly backs your interpretation.  I
admit that I had not noticed this note previously, which is an oversight
on my part.  However, Clause 0.2.3 states that "notes... are not part of
the definition of the language".

Going back to the above quote from your email, I would like to consider
the following phrase more closely:

  "...no information in the context outside of the expression is used in
   this determination."

I agree with you that there is no _type_ information available from the
context outside the expression.  However, there is _some_ information
available.  That information is the fact that there is no type
information available, and that the type conversion operand must be, in
essence, of a self-determined type.

This is drawing on a very fine point here. As I understand your analysis
(and please correct me if I am wrong) you are disallowing any use of the
fact that the concat is within a type conversion in resolving the
overloaded operator.  Since there are two valid concat operators visible
at this point, your contention is that the expression is ambiguous.
However, 10.5 defines the "complete context" for overload resolution as
a declaration, a specification, or a statement.  In this case, the
complete context is a statement; specifically, a concurrent assignment
statement.  It is my contention that the fact that the operand of the
type conversion must be self-determined is relevant and contributes to
the overload resolution of the concatenation.

The central point from my previous email is that Clause 7.2.4 provides
additional rules for choosing between the two different visible
signatures of the concat operation.  If overload resolution as defined
in 10.5 is the ultimate end in resolving this, then I would have to
agree with you.  However, if 10.5 contains the final say for this
question of overload resolution, then much of the text in 7.2.4(c)
becomes excess verbiage, as it cannot have any effect.  Thus I believe
that the text of 7.2.4, specifically (c), does apply in determining
whether the concat under question is ambiguous or not.

The first sentence of (c) reads:

  "If both operands are of the same type and it is the element type of
   some one-dimensional array type, the type of the result must be known
   from the context and is this one-dimensional array type."

This sentence is of the form "if (A) then (B)."  In this case (A) is
agreed on as being true.  Therefore, logically, (B) must also be true if
mutually exclusive case (c) is to be valid.  However, in this situation
(B) cannot be true because the type of the result cannot be known from
the context.  The context in this case is that of the operand of a type
conversion.  While the type conversion provides no context at all for
determining the type of its operand, the fact that it provides no
context may be used when interpreting 7.2.4(c), disallowing it as an
invalid interpretation as defined in 10.5.  This leaves 7.2.4(a) as the
only valid case of the three mutually exclusive cases, and thus the
concat unambiguously resolves to &(T, T) return T.

This brings up another question; the use of "mutually exclusive" as
applied to 7.2.4 (a), (b), and (c).  This on the surface appears to be
inconsistent with the text of Note 2 at the end of the clause.  This is
irrespective of the resolution of the issue at hand.  I indirectly
mentioned this inconsistency in my request for clarification to ISAC.
When the voting finally opens up for 1076-2007(8?) I'll make sure to
raise this point, if we do not come to an agreement that changes my
thinking here. 

Thanks and Regards,
-- 
Tim McBrayer                                       508-647-4229
The MathWorks                        tim_mcbrayer@mathworks.com