ISAC: Minutes of meeting held on 02 March 2006

These minutes are also available online.

Chuck Swart


Minutes of ISAC meeting help via telecom on 02 March 2006

Present: Peter Ashenden, Larry Soule, Chuck Swart
Absent: Jim Lewis, Ajay Verikat

Next Meeting: Thursday March 16, 2006, 6 pm Pacific Standard Time
              (Friday March 17, 2006, 2am GMT)

NOTE: It was agreed to meet again in two weeks to try to clear the
backlog of issues (we have about 10 unresolved issues.)

TOPIC: New members.

We are still looking for one or two more members.

ACTION: Chuck to contact prospects. All to look for new members.

TOPIC: IRs 2075, 2080, 2081

These were voted on and passed, so are ISAC approved.

ACTION: Chuck to pass these on to VASG.

TOPIC: IR 2084  A record "element" is not called a "field"

The analysis is correct. This IR is ready for ISAC vote.

ACTION: Chuck to submit, all to vote.

TOPIC: IR 2085 What happens when a parameter of mode out is not
assigned in a procedure?

It was agreed that, although it takes some work, the LRM is clear that
parameters are initialized to type'left, so that the results of an
unassigned or partially assigned composite are well-defined.Various
relevant clauses are: 2.1.1.1,12.2.1-12.2.4, 12.3.1.4, 12.5.  There
was some discussion about relaxing the initialization requirement,
since initializing arrays can be costly. It was agreed that relaxing
this requirement could break models which assume initialization of
inputs.

ACTION: Chuck to analyze.

TOPIC: IR 2086 Incorrect description of type mark in disconnection
specification

It was agreed that the proposed resolution was essentially correct.
However, in each of the four cases "the subtype must denote" should be
replaced by "the subtype must be". This is a more stringent
requirement but appears to match the current rules regarding
disconnection specifications.Also, on page 86 change:
"signal S of whose type mark denotes the type T" to "signal S specified with
type mark T." This slight rewording is more accurate.

ACTION: Chuck to write up.

TOPIC: IR 2087 Ambiguous rule for type of an alias declaration

Claus 4.3.3.1 Object aliases has a section b) which requires that "The
base type of the name specified in an alias declaration must be the
same as the base type of the type mark in the subtype indication (if
the subtype indication is present); this type must not be a
multidimensional array type. The submitter points out that it is not
clear to which type "this" refers to. In addition, the reason for
forbidding multidimensional array types is not clear.

It was agreed that whatever "this" referred to, the restriction
against aliasing multidimensional arrays didn't make sense and should
be removed.  The matching element requirement prevents illegal
reinterpretation of multidimensional arrays.

Also, the reported typo is b)(1) is genuine. (We are ignoring the
issue of whether a slice has a subtype, since this issue is
pervasive.)

ACTION: Larry to write up.

TOPIC: IR 2077 Incorrect wording on some language constructs

The language changes proposed by the submitter were accepted. The
analyzer found additional similar instances. Peter pointed out that
there could be additional similar cases in the LRM, such as references
to "file type" or "protected type." The IR will be slightly reworded
to suggest that the LRM revision contain similar rewording as
appropriate.

ACTION: Chuck to revise, the submit for vote, all to vote on.

TOPIC: IR 2062  Range staticness

This IR was approved by the VASG, but a negative vote correctly
pointed out that the solution was not general enough. G'RANGE could be
used for the discrete range in generation scheme where G is a generic,
but P'RANGE cannot, although it is equally valid.  Two possible
solutions were 1: remove requirement that the discrete range in a
generation scheme be static. or 2: Make additional changes to the
definition of staticness. The first choice is not completely
satisfactory, since the use of impure functions could cause
implementation-dependent order dependencies.The second choice will be
attempted. It was also noted that the attributes 'length and
'ascending should be functions, not values.

ACTION: Chuck to analyze.