ISAC: Minutes of meeting held on January 12, 2006

Please review these minutes.

Minutes of ISAC meeting held via telecom on 12 January 2006

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

Absent: Deepak Pant

Next Meeting: Thursday February 02, 2006, 6 pm Pacific Standard Time
              (Friday February 03, 2006, 2 am GMT)

TOPIC: Vote on ISAC-Approved IRs.

Voting closed on Thursday, too early for report at this meeting.

ACTION: Jim (VASG chair) to email vote results for ISAC analysis and
        response.  Chuck to forward to Jim recently ISAC-Approved IRs.

TOPIC: IR 2080 Case expression should include parenthesized expression

There was some confusion about the details of the wording changes,
because it was realized that clause 8.8 needed two textual
changes. However, the requested changes are reasonable (and several
implementations already support this).

ACTION: Peter to revise the IR to include both textual changes (done).
Chuck to analyze and submit to ISAC for electronic vote.

NOTE: It was agreed that all ISAC/VASG IR changes should be submitted
to the LRM writer by May at the latest.

TOPIC: IR2058 does USE of type name make operators and literals visible?

Jim Lewis presented an example similar to the following:

...
use ieee.std_logic_1164.all;
package my_types is

    subtype sl is std_logic;
...
end package my_types;

...
use work.my_types.all;
entity test_my_types;
end entity test_my_types;
architecture test of test_my_types;
...--what's visible in here
end architecture test_my_types;

The general thought is that subtypes carry with them enumeration
literals and physical units, but that general operators are not
"transitive."  When Chuck wrote the proposed wording for the IR he was
not thinking primarily of transitivity issues. Therefore, the IR will
be reopened.

ACTION: Chuck to reopen the IR and raise questions related to this
example.  Peter to review the revised IR.

TOPIC: IR 2063 Unconstrained array formals should not get subtype from actuals
 
This IR was forwarded to VASG because the changes were part of FT-14.
Peter sent an email describing the LRM changes related to FT-14 and
asked the ISAC to review them.

ACTION: All to review Peter's email.

TOPIC: IR 2074 Problem with direct/select visibility in formal part

As a result of the ISAC vote, several issues were raised concerning
the latest analysis.  Jim preferred that both cases A) and B) be
illegal.  Peter believes that select visibility has precedence over
direct visibility throughout the formal part, so that x01(x01) is
illegal.  There was also confusion about wording regarding
actuals. The visibility rules favoring select names are intended to
apply to local parameters used as actuals, not to all actuals.

ACTION: Chuck to revise;

TOPIC: IR 2054 Individ. assoc. rules for array formal are not valid

(My notes say that Peter will examine, presumably in light of LRM
changes which have already been written. Peter, can you verify this?)

ACTION: Peter to examine.

TOPIC: IR 2079 Is TIME a locally static type?

Chuck mentioned that one possible solution of stating that type TIME is not
locally static is intriguing, but would probably imply the TIME'POS
returns the number of resolution limit units. This is most likely not
backward compatible.

Also, there is a general problem in that TIME values are usually 64
bits in current implementations, which INTEGER values are often 32
bits.  But some arithmetic operations on TIME require conversions to
INTEGER, which might technically cause overflow. Also, many arithmetic
operations on TIME require TIME'POS which is of type universal_integer
and is only required to be as accurate as the largest integer, so
again, unwanted overflow could occur. However, most implementations
give the expected results on time arithmetic even though there are
sometimes technical violations of the LRM.

ACTION: Chuck to continue analysis.