Copyright (C) 2000-2012 |
GNU Info (g77-300.info)More ExtensionsMore 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 `OPEN'ed,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. |