Title: TYPEDEF facility Submitted by: J3 (Aleksandar Donev, February 2004) Status: For Consideration References: J3/03-256 Basic Functionality: Bring back the previously removed TYPEALIAS facility (see History) as a TYPEDEF facility to be used in C Interop. This facility would allow one to give alias names to other types. This facility may be restricted to interoperable types only if so desired. A proper and better designed Fortran TYPEALIAS facility may then be developed separately, not compromising the very urgent C Interop void created by the removal of TYPEALIAS. Rationale: C has a typedef facility which allows one to give aliases to existing C types. These are used very widely, and therefore we need to provide a way to easily interface with libraries that use them. Header files are central to "portability" in C, and they usually mainly consist of preprocessing directives like #defines, function prototypes and typedefs. The first seem outside the scope of Interop and can be emulated with PARAMETERs, the second are handled already, and now we also need to be able to handle typedefs. The goal is to be able to write a Fortran module that emulates a header file provided by the vendor of a library, and that someday it may even be possible to do an automatic .h -> .f90conversion (at least an initial stage thereof). Here is a short piece of the include file GL/gl.h which is the central include file for the OpenGL library: ... typedef unsigned int GLenum; typedef unsigned char GLboolean; typedef unsigned int GLbitfield; typedef void GLvoid; ... #define GL_BYTE 0x1400 #define GL_UNSIGNED_BYTE 0x1401 ... GLAPI void GLAPIENTRY glTexCoord1dv( const GLdouble *v ); GLAPI void GLAPIENTRY glTexCoord1fv( const GLfloat *v ); for which one should be able to write an equivalent module: MODULE GL USE ISO_C_INTEROP TYPEDEF :: GLenum => INTEGER(C_INT), & GLboolean => CHARACTER(C_CHAR), ... TYPE(GLenum), PARAMETER :: GL_BYTE =... INTERFACE SUBROUTINE glTexCoord1dv(v), BIND(C) TYPE(GLdouble), DIMENSION(*), INTENT(IN) :: v END SUBROUTINE ... END INTERFACE END MODULE GL As another example, consider writing a Fortran interface to the MPICH implementation of MPI. Typically, this will be a module that contains various constants, type parameters, and interfaces. MPI uses many typealiases, which are needed when writing interfaces. For example, MPI_Datatype is typically an alias for int. But one cannot assume this, nor that it is indeed an integer. One cannot get away with our untyped C_PTR, since arguments of type MPI_Datatype are passed by value, not by reference. It is necessary for any kind of portability that one be able to write: TYPEDEF :: MPI_Datatype => INTEGER(KIND = C_INT) in the module for the interface to MPICH. Estimated Impact: The complication is mostly syntactic. The same issues we had with TYPEALIAS remain. If we restrict this facility only to interoperable types some of the problems may go away (for example, no more parameterized types). Detailed Specification: Same as previous TYPEALIAS, but called TYPEDEF, possibly restricted only to interoperable types. History: Peter Crouch, FSG Web Editor: A search of the FSG website revealed a description of the TYPEALIAS facility as originally proposed for Fortran 2000 in Malcolm Cohen's presentation on Data Manipulation Enhancements at the Fortran 2000 Forum, (www.fortran.bcs.org/forum2002/f2000dme.htm#misc). Its fate is described in two reports by John Reid, one on the Fortran 2000 Forum, (www.fortran.bcs.org/forum2002/f2000report.htm) and the other presented to the 2003 AGM, on the WG5/J3 Meeting in Las Vegas, March 30 to April 4, 2003, (www.fortran.bcs.org/2003/ukfortran03.htm). In summary the facility was removed at the request of the UK delegation as a result of a straw poll taken at the Fortran 2000 Forum! Comments: Malcolm Cohen, Nihon NAG, Tokyo: I disagree on a number of points of fact in this submission. I disagree that it would solve the problems it is claimed to solve; mostly it merely introduces variant syntax for already-existing solutions (and that variant syntax makes life actually more complicated IMO). Also, I am strongly opposed to adding any such feature for "C interoperability" only. If this feature is so essential, it should be added for everyone. Doing that would involve resolving the competing "it produces a new type" vs. "just as alias for an existing type" requirements. C interoperability wants the latter, but more normal uses would find the former better because it has better error detection. Maybe this could be resolved simply by a keyword specifying what the user wants. Or maybe we just do the C interop version. But if it is so essential (and it isn't, but since the proponents say it is...) then we should let everyone have it. For example, the proposal says "MPI_Datatype is typically an alias for int. But one cannot assume this, nor that it is indeed an integer." Right, and making MPI_Datatype a TYPEALIAS still doesn't solve the problem, because you still need to define the constants that all of them are, and you need to know exactly what the internal structure is (and incidentally, what the values are) as well. No attempt has been made to solve the problems which plagued TYPEALIAS before (admittedly, these were mostly of exposition), apart from a pious hope that they will "go away" by restricting it to interoperable types. But there are still type parameters (for the intrinsic types) so one still needs some of the answers. If we're going to do one that is just an alias, let's call it TYPEALIAS and have it be a fixed version of what was in the F2003 draft. Let's not do a half-baked half-solution. SUMMARY: (1) J3, which is the committee which most liked typealias before, has shied away from doing this. (2) It is moderately complicated - even just doing the same "technical effect" as before needs quite some careful wordsmithing to avoid possible ripple effects throughout the standard (cf. Richard Maine's comment on any change to the type system being automatically a "large" feature). (3) If we do it, it would be nice to satisfy the people who want typealiases to be new types not just aliases. (4) Do it right or not at all.