J3/97-224r1 page 1 of 2 To: X3J3 From: Interval2 Subject: Should Intervals be specified via a Module? Date: Aug. 12, 1997 What is a MODULE good for? - Among other uses, Modules were intended to support abstract data type specification/implementation. - Interval 2 believes that Modules should be used for adding new datatypes to the base language, particularily for new datatypes which are not of interest to the vast majority of users. This applies to both user defined datatypes and "standard" defined datatypes. - Philosophically, if Modules are inadequate for this purpose, we should fix the base language to support this use!!! - Note that a "Module" specification of a feature does not prevent a processor from supporting the feature intrinsically. What does a good Interval datatype need from the processor? From Interval 1's paper 97-170, - guareenteed containment, all the time - speed * an intrinsic implementation must at least be an option - sharpness * mathematically equiv. compiler transformations are needed (see 97-158, 97-199) - convenient syntax * I/O should not be ugly * operator precedence must make sense, and therefore be specifiable A simplistic Module implementation based on F95 violates these requirements in several ways: - containment when doing formatted I/O is not available - efficient arithmetic operations not available - mathematically equiv. compiler transformations require an intrinsic implementation, but NOT an intrinsic datatype - different operator precedence is not available - PARAMETER statements for an Interval type object are not available for an abstract type - containment when converting REALs to Interval is problamatic J3/97-224 page 2 of 2 Should interval arithmetic be specified as an intrinsic datatype, or as a Module, accessed via a USE statement? - This is really a philosophical question. - If you believe Modules should be used for new datatypes, the question becomes: What should we add to the base language to support new types being specifed as a Module? This question is addressed later. - NOTE that a Module specification DOES NOT imply that the feature will be implemented via Fortran 95 source code in a Module. A processor which implements such a Module specification of a new feature intrinsically can usually provide the same compile time and runtime performance as an implementation of the same feature as an intrinsic datatype. Therefore, performance of a new datatype should not be a reason to require that datatype to be specified as an intrinsic datatype. Certainly some implementors might chose to use a Module source code approach, with its inferior runtime performance, but I do not believe such an implementor would implement the feature at all if an expensive intrinsic implementation was required. What should we add to Fortran 95 to enable the use of Modules to implement new datatypes? - Rounding modes for arithmetic operators What cannot be handled with a Module Implementation of Intervals - high performance * potentially slower handling of rounding modes for arithmetic operations, * arithmetic operators are inefficient (function call, possibly inlined) - sharpness * mathematically equiv. compiler transformations are impossible - convenient syntax * no operator precedence * I/O edit descriptors are two characters longer FORMAT (..... DTxxx ... ) -- is this really ugly? What cannot be handled cleanly with a Module specification but an intrinsic implementation? - no operator precedence - Compile time PARAMETERs/Constants of the new datatype * extensions to F95 could allow for this - can't do widest need for mixed mode So, why NOT use a Module specification for the Interval datatype?