ISAC: Minutes from meeting on 09 January 2008

These are also available at the website.
Chuck


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


Minutes of ISAC meeting held via telecom on 09 January 2008

Present: Peter Ashenden, Larry Soule, Chuck Swart, Ajay Verikat

Absent: Jim Lewis, Lance Thompson

Next Meeting Thursday, February 07, 8 pm Pacific Standard time
             (Friday, February 08, 4 am GMT)

TOPIC: IR 2126 Concatenation ambiguity 

The submitter points out an issue with regard to the [element,element]
return array_of_element case of concatenation. The LRM says (7.2.4
paragraph c) that "the type of the result must be known from the
context". However, the LRM also says (7.3.5) that for type conversions
"The type of the operand of a type conversion must be determinable
independent of the context (in particular, independent of the target
type)." The submitter concludes from these two statements that the
[element, element] case is not a valid candidate for an operand of a
type conversion. This seems to contradict clause 10.5 which states
"For overloaded entities ... all visible declarations are considered."
The inconsistency appears to apply to a wider range of expressions
because clause 7.1 states: "for an overloaded operand or operator, the
determination of the operand type, or the identification of the
overloaded operator, depends on the context." This situation is at
best confusing and at worst contradictory.

The LRM has three areas which state that certain types must be
determined independent of context. These areas are discrete ranges
defined by a range in constrained array definitions, iteration schemes
or generation schemes (3.2.1.1), type conversions (7.3.5) and case
statements (8.8).  These areas are intended to restrict type checking
in specific ways.  Many implementations interpret "independent of
context" in an informal way. In particular, it is unreasonable to
ignore all of clause 10.5, even in areas "independent of context".

The ISAC believes that these areas are confusing, perhaps
contradictory.  It would be better to rewrite the LRM to describe the
specific restrictions on type checking and to remove the references to
"independent of context".

ACTION: Chuck to analyze.

TOPIC: IR 2127 Possible LRM interpretation pitfall related to the
predefined STANDARD package

The submitter reports that there is a problem when he declares a
function named "min" in a package and then refers to that "min" in a
USE clause.  One tool makes the "min" function directly
visible. Another tool does not make it visible because it conflicts
with the time unit declaration of "min" in package STANDARD.

The ISAC believes that the LRM is quite clear on this. Clause 10.4,
subsection starting with b) (VHDL-2002) clearly states that neither
"mins" is directly visible.

A minor issue: In the Proposed Resolution section the submitter
mentions that one tool "does not consider that an 'and' in STANDARD
clashes with an 'and' in std_logic_1164. Chuck contacted the submitter
via email and pointed out that the tool was correct, since none of the
'and' functions were homographs. The submitter concurred.

An interesting side issue was raised. The submitter mentioned several
tools by name. The question was raised whether this was proper and in
accordance with IEEE rules and guidelines. From a practical
perspective, it is often advantageous for the ISAC to know specifics
of tool behavior.  Opinions of particular implementors can thus be
sought. On the other hand, the ISAC and VASG must be careful not to
recommend one tool over another.  It was decided that it is OK for the
submitter to mention specific tools, but the analysis and
recommendations should be presented in a neutral manner.

ACTION: Peter to analyze.

TOPIC: IR 2119 Can't declare a protected type and object of that type
in a single package

This IR was technically VASG-Approved but several voters suggested
that the forbidden behavior be allowed. The ISAC decided to forward
this as a language change requirement. Peter added the ISAC's opinion
on this to the IR.  Peter's additional comments are accepted. The IR
will be forwarded as a requirement.

ACTION: Chuck to forward to VASG chair.

TOPIC: IR 2123 Process resumption and callbacks 
       IR  2124 Ordering of process execution and callbacks

Ajay contacted Francoise about these issues, who emailed Chuck.  There
has been no action reported to the ISAC for almost two months.  If
responses to these IRs are going to be incorporated into the next
version of the language, then VHPI needs to act.

ACTION: Chuck to contact VHPI chair.