J3/02-317R2 Date: Nov 13, 2002 To: J3 From: Dick Hendrickson Subject: Response to Public Comment #1 from Todd Plessel > From: Todd Plessel > Sent: Wednesday, October 9, 2002 9:35 PM > To: Donovan, Deborah > Subject: Comments on draft Fortran 2000 Spec. > > > ftp://ftp.j3-fortran.org/j3/doc/standing/2002/02-007r3/007.txt.gz > > Some suggestions: > > > 24 3.3.1 Free source form > > 25 In free source form there are no restrictions on where a statement > >(or portion of a statement) may > > 26 appear within a line. A line may contain zero characters. If a line > consists entirely of characters of > > 27 default kind (4.4.4), it may contain at most 132 characters. If a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > line contains any character that is not > > > #1. Maximum line length should be changed to something much larger (4096 or > more - like Standard C) > to accommodate macro expansion (a form of code-generation). > NO, we've chosen to allow more continuation lines instead. We feel that longer lines will not be readable by humans (including when listed in error messages). We recognize that preprocessors will need to be aware of the 132 limit, but they would need to also be aware of any other limit and do some sort of special casing for the line-too-long case. > #2. The Standard should address the Standard Preprocessor and make it 100% > compatible with > the Standard C Preprocessor, including: > token glue operator '##', __FILE__, __LINE__, __FUNCTION__. > (These are needed to implement Design By Contract assertion macros.) > NO, we have chosen to standardize a more Fortran-like preprocessor as a separate standard. > #3. Add direct support (language syntax) for Design By Contract: > o class invariants > o routine preconditions > o routine postconditions > o check assertion > o loop invariants > o loop variants > o debug statement > optionally checkable (depending on compilation flags) at runtime. > NO, this was not on the agreed list of features for F2K and is too large to add at this time. We will suggest that it be added to the list of features for consideration for the next revision of the Fortran standard. > #4. Add support for program arguments (like C main( int argc, char* argv[])) > and an integer > return value for program (to facilitate interoperability with other > programs/processes). > NO, not as specified. However, we have added a set of intrinsic subroutines that provide the same functionality as the argc/argv method. See section 13.5.17, command_argument_count, get_command, get_command_argument. NO, adding an integer return value was not part of the requirements for F2k. We believe it is too system dependent for consideration at this time. We will suggest that it be added to the list of features for consideration for the next revision of the Fortran standard. > #5. Make the process name, (contained in argv[0] in C), available via a > Standard Library function, e.g., > FUNCTION PROCESS_NAME > CHARACTER(*) PROCESS_NAME > (This will facilitate the construction of useful failure messages within > reusable libraries. > Perhaps with thead id too...) The get_command and get_command_argument intrinsic subroutines provide this capability. > > #6. Provide Standard Library routines for registering callback > subroutines/functions: > atstart, atstop to facilitate initialization and finalization of external > (possibly non-Fortran) > subsystem code (e.g., database libraries). See 'man atexit' which does > half of this for C. > NO, this was not a requirement for F2K. However, procedure pointers and C interoperability provide much of the functionality. > That's a start. I can elaborate on any of these if needed. > > Todd