This document contains assorted e-mail discussions about open interpretation requests. The contents of this document have not necessarily been reviewed or approved by the interpretations subgroup. ------------------------------------------------------------------------------- 205 I do not know the current status of my request #205 regarding EXTERNAL, but I would advocate to forbid an EXTERNAL specification for a procedure inside that subprogram's definition. This can be motivated by the corresponding constraint for INTERFACE blocks, which reads: [X3J3/96-007, WG5/N1176 194:16+]: "Constraint: An in a subprogram shall not contain an for a procedure defined by that subprogram. Best regards, Michael Michael Hennecke http://www.uni-karlsruhe.de/~Michael.Hennecke/ ------------------------------------------------------------------------------- 212 From Craig: Practical considerations: Developing applications under MS-DOS often requires use of the MS-DOS system routines (i.e., the INT xx interrupt routines). These routines were originally designed primarily for access by users of 80x86 assembler. They were NOT designed for use by Fortran programmers. Thus, they necessarily make reference to values in the 80x86 registers. Sometimes the MS-DOS interrupt routines use or return values in full (16 bit or 32 bit) registers while in other cases they use or return values in 8 bit half registers. The same routine can use both practices. In the past, I have used the Lahey F77L Fortran compiler to develop applications under MS-DOS. This includes calls to MS-DOS system routines using the Lahey-supplied INTRUP subroutine. This subroutine takes as one of its arguments an INTEGER array which supplies data to and reads data from the 80x86 registers. The F77L compiler allowed a programmer to use the EQUIVALENCE statement to equate the definitions of the half registers with those of the full registers. When I tried porting this practice to the Lahey LF90 Fortran 90 compiler, I found that the LF90 compiler did not allow it. When I checked the standard, I found the constraints quoted above. Other methods are available. I could use MVBITS and other bit intrinsics to obtain the functionality that I need. This approach would use more memory and processor power than using EQUIVALENCE. The use of bit intrinsics is also much more cumbersome, indirect, and produces less readable code than the use of EQUIVALENCE. It would be very useful to have this functionality available, at the least as an extension to the standard. Using EQUIVALENCE in this application is much more straightforward than using other methods. From Richard Maine: > 1. Why are these constraints in the standard? What useful purpose > do they serve? What problems do they prevent or solve? You don't have to read the committee's minds to deduce this - it is pretty evident from the nature of the constraints. The constraints allow everything that was legal in f77. Things new to f90 are allowed only in very restrictive forms. The pretty clear intent was to deprecate the use of equivalence and storage association, at least in its "wilder" forms, with new features. I noticed this general pattern the very first time I skimmed a draft of what was then f8x, long before I knew anyone on the committee. Also note that, since the relationships between the sizes of, for example, different integer kinds, is completely processor dependent, the standard wouldn't be able to say much useful about what equivalences among those kinds would do. > 2. Could a standard-conforming processor relax or eliminate one or > more of these constraints, as an extension, without sacrificing full > conformance to the standard? Of course. In fact most of the compilers I've used (getting to be a pretty sizeable set, though far short of the number that exist) do allow such extensions and still claim conformance. The standard allows extensions - this no different from any other. The only caveat is that there has to be at least a compiler option to diagnose that an extension is being used. > 3. Can a data object of sequence derived type be equivalenced to > another data object of a different sequence derived type? Yes. The rules for sequenced types are pretty trivial. The sequenced type is ultimately a sequence of storage units of basic types. Anything you could do with those basic storage units, you can then do with the sequenced type. So the answer to questions 3, 4(omitted) and 5 (also omitted) are all yes. > Example:... > TYPE T1 > SEQUENCE > INTEGER (1) I1_ARRAY (36) > END TYPE > > TYPE T4 > SEQUENCE > INTEGER (4) I4_ARRAY (9) > END TYPE ... But this example is illegal because you could not equivalence the basic storage units involved. Dropping them into a sequenced type makes no difference. It would be silly to allow equivalence of things in sequenced types that couldn't be equivalenced separately. This would just force people to make spurious types just to get around the restriction. > Other methods are available. I could use MVBITS and other bit > intrinsics to obtain the functionality that I need. TRANSFER is the canonical replacement for equivalence. True, I sometimes find equivalence more convenient than TRANSFER. I don't see any real questions of interpretation here. The standard seems pretty explicit. I don't recall anyone ever suggesting a possible alternative interpretation. It also seems pretty clear that the restrictions were intentional, rather than accidental. One might plausibly ask for relaxation of some of these constraints in a future version of the standard (I don't know whether it would be accepted, but it is at least a plausible thing to request). But I don't see any grounds for treating this as an interpretation issue. P.S. Please hit carriage returns every once in a while. It is pretty difficult to read paragraphs that are all on one line. Some mail readers handle it automatically, but that is an "extension", not a requirement of the standard. :-)