Minutes of ISAC meeting held via telecom on 03 February 2005 Present: Peter Ashenden, Jim Lewis, Deepak Pant, Larry Soule, Chuck Swart, Ajay Varikat Absent: Next Meeting: Thursday 17 February 2005, 7 pm Pacific Time TOPIC: IR2057 Access-typed parameters to predefined "=" and "/=" It was agreed that the implicit = and /= operators create an inconsistency. The suggestion was to allow access types as CONSTANT parameters to pure functions and to establish that functions which violate purity by update designated values are erroneous. ACTION: Chuck to analyze. NOTE added: The problem is deeper than the submission indicates. See the analysis. TOPIC: IR2058 Does USE of type name make operators and literals visible? It was agreed that Peter's analysis, which concluded that only the type name was made visible, was correct. It was also agreed that such a strict interpretation severely restricted the utility of the USE of a type name. Several implementations do not follow the strict interpretation. If we expand the visibility for USE type statements, some issues are: a) What do we make (potentially) visible? enumeration literals implicitly defined operators and subprograms overloaded operators and subprograms all operators and subprograms in the package which contain the type b) What kind of type marks in USE type statements create this extended visibility? types only types and first named subtypes all subtypes It was pointed out that if changes are made here, then type aliased should also be changed for consistency. As a stake in the ground, Chuck will try a first cut at resolving these issues. ACTION: Chuck to analyze. TOPIC: IR2059 Upper/lower case character mapping is not clear It was agreed that the LRM does not clearly specifically identify upper case vs lower case letters, nor their mapping although the correct mapping is pretty obvious. Neither does the ISO standard for these characters, although the names commonly used for them does imply case. The easiest solution is to explicitly provide the mapping between upper and lower case. ACTION: Peter to analyze, then all to vote. TOPIC: IR2060 Include truth table for multi-input/multi-output logic. This will be forwarded to the Modeling and Productivity Group. ACTION: Chuck to forward. TOPIC: IR2056 Can an attribute name that denotes a function be used where a name is required? This was approved, subject to a trivial editorial change. ACTION: Chuck to send to VASG chair. TOPIC: IR2013 Exact subtype "matching" for port associations It was suggested that the discussion of the possible solutions be moved from the Recommendation area into the analysis area. ACTION: Chuck to update then all to vote. TOPIC: IR2043 Numeric VALUE attribute parameter can't have sign This work is closely related to Peter's work on FT05: "to_string". The strings which are valid for READ procedures should be compatible with strings as input to the VALUE attribute. However some technical details need to be worked out. It was suggested that for the 2002 version of the language we state that an optional sign is legal, similar to what is stated in textio. For future versions, to_string, 'VALUE and the READ and WRITE procedures should all be carefully coordinated. ACTION: Deepak to analyze. TOPIC: IR2049 Circular definition of an event on a signal Subject to minor editorial change, this was approved. ACTION: Chuck to send to VASG chair.