ISAC: Minutes from meeting on 06 September 2007

From: Chuck Swart - MTI <cswart_at_.....>
Date: Fri Sep 07 2007 - 14:55:26 PDT
These minutes are also available on the website.

Chuck Swart


-- 
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 06 September 2007

Present: Peter Ashenden, Chuck Swart, Lance Thompson, Ajay Verikat

Absent: Jim Lewis, Larry Soule

Next Meeting Wednesday, October 10, 2007, 8 pm Pacific Daylight Time
             (Thursday, October 11, 2007, 3 am GMT)

TOPIC: IR 2120 How to access objects in higher level nested protected type

The committee looked at declarative regions which are not legal for
expanded names. They are: configuration declarations, record type
declarations, component declarations, component configurations and
protected type declarations.

With the exception of protected type declarations, the other regions
have very restrictive purposes and there is little or no benefit to
allowing expanded names for those regions. As the submitter pointed
out, there is good reason for allowing expanded names in protected
type declarations.The committee believes that the omission of
protected types from the list of expanded names was an oversight.
Note that the example the submitter gave of a selected name into a
record type is not an expanded name. The committee determined that
there were not sufficient use cases to pursue extension of selected
names into record types.

ACTION: Peter to analyze.

TOPIC: IR 2121 Allow for vectors to have assigns and opens in the port map

VHDL-93 and following forbid partial association, but the exact
reasons for this are lost. There is no IR on this. The change was put
in in response to a ballot remark, but the ballots are no longer
available. VHDL-87 does not forbid partial association, but its not
clear what the semantics are. There does not seem to be any difficulty
with partial association of OUT ports. For IN ports you need some rule
to determine the value of the unconnected parts. A reasonable
interpretation is to evaluate the (entire) initial expression, then
use the appropriate pieces of the initial value for the unconnected
parts.

ADDED LATER: one possible problem is a "forgotten" association.
Suppose port P is of type bit_vector( 1 to 3). Currently, if you say
P(1) => S1, P(2) => S2 you will get an error message. Under the
proposed extension this might be legal. One solution would be to allow
partially unconnected ports, but to disallow partially unassociated
ports, i.e.  you must explicitly say P(3) => OPEN.

ACTION: Chuck to contact various groups for the history of this
problem and for potential difficulties.

TOPIC: operators used as methods.

Chuck wasn't clear about how operators could be used as methods. The
answer is that operators may occur as methods. The have one less
parameter than the corresponding subprogram declaration. So, for
example, binary + would have one argument as a method and it would be
invoked only in subprogram notation: x."+"(y) instead of x+y. These
rules do give a semantic meaning to operators as methods, although
their use may seem cumbersome.

ACTION: none.


TOPIC: IR 1070 VPI Issue 14 -- Prefixes in USE clauses

Peter's analysis seems to be correct. The bottom line is to interpret
a library clause as if it were a library declaration. However, some
members wanted time to think about this interpretation. To give people
time, we will vote electronically.

ACTION: All to vote.

TOPIC: IR 2099 Alias declarations introduce homographs

This IR is associated with Bugzilla Issue #131. Most people think that
if homographs of a function are each declared in two packages, and if
both of those packages are USED, then neither function is made
directly visible. However, a literal interpretation of the LRM says
that both functions are made visible. Most references to either
function are ambiguous, but if the functions have different parameter
names, then named association can possibly be used to distinguish
between them. At least one simulator supports the literal
interpretation of the LRM. Although changes need to be made to the LRM
to give explicitly declared subprograms priority over implicitly
declared homographs, it is desirable to preserve the current behavior
as much as possible.

ACTION: Chuck to reconcile IR 2099 with Bugzilla #131.


TOPIC: IR 2110 Implicit subtype conversions not defined

No change.

ACTION: Chuck to analyze.

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

Peter's analysis is accepted. Similar restrictions apply to deferred
constants and, especially, subprograms declared in packages.

ACTION: Chuck to contact submitter. Either ISAC will vote on the IR or
we will make this an enhancement request, depending on the submitter's
response.

TOPIC: Status of pre-2002 IRs.

No change.

ACTION: Chuck to move them to Bugzilla.
Received on Fri Sep 7 15:22:48 2007

This archive was generated by hypermail 2.1.8 : Fri Sep 07 2007 - 15:22:53 PDT