21.4 More Extensions

These extensions are not the sort of things users ask for "by name", but they might improve the usability of g77, and Fortran in general, in the long run. Some of these items really pertain to improving g77 internals so that some popular extensions can be more easily supported.

• Look through all the documentation on the GNU Fortran language, dialects, compiler, missing features, bugs, and so on. Many mentions of incomplete or missing features are sprinkled throughout. It is not worth repeating them here.

• Consider adding a NUMERIC type to designate typeless numeric constants, named and unnamed. The idea is to provide a forward-looking, effective replacement for things like the old-style PARAMETER statement when people really need typelessness in a maintainable, portable, clearly documented way. Maybe TYPELESS would include CHARACTER, POINTER, and whatever else might come along. (This is not really a call for polymorphism per se, just an ability to express limited, syntactic polymorphism.)

• Support `OPEN(...,KEY=(...),...)'.

• Support arbitrary file unit numbers, instead of limiting them to 0 through `MXUNIT-1'. (This is a libg2c issue.)

• `OPEN(NOSPANBLOCKS,...)' is treated as `OPEN(UNIT=NOSPANBLOCKS,...)', so a later UNIT= in the first example is invalid. Make sure this is what users of this feature would expect.

• Currently g77 disallows `READ(1'10)' since it is an obnoxious syntax, but supporting it might be pretty easy if needed. More details are needed, such as whether general expressions separated by an apostrophe are supported, or maybe the record number can be a general expression, and so on.

• Support STRUCTURE, UNION, MAP, and RECORD fully. Currently there is no support at all for %FILL in STRUCTURE and related syntax, whereas the rest of the stuff has at least some parsing support. This requires either major changes to libg2c or its replacement.

• F90 and g77 probably disagree about label scoping relative to INTERFACE and END INTERFACE, and their contained procedure interface bodies (blocks?).

• ENTRY doesn't support F90 RESULT() yet, since that was added after S8.112.

• Empty-statement handling (10 ;;CONTINUE;;) probably isn't consistent with the final form of the standard (it was vague at S8.112).

• It seems to be an "open" question whether a file, immediately after being OPENed,is positioned at the beginning, the end, or wherever--it might be nice to offer an option of opening to "undefined" status, requiring an explicit absolute-positioning operation to be performed before any other (besides CLOSE) to assist in making applications port to systems (some IBM?) that OPEN to the end of a file or some such thing.