lagache@violet.berkeley.edu (Edouard Lagache) (02/07/88)
I am disturbed (to put it mildly) by some of the comments on why some reasonably obvious features have been omitted from FORTRAN 8x. Lets take a look at some of them: 1.) INCLUDE: The standard reply is that by eliminating the need for common blocks, one will eliminate the need for this statement - huh? "C" has an include statement, and have never had common blocks. It is unreasonable to suppose that I might want to have a header file of derived types, or symbolic constants, or macros (more on that later). 2.) WHILE: FORTRAN 8x contains looping constructs that are more powerful than WHILE. So what? When I am trying to read in some indefinite number of items from input, what I need is a WHILE loop (or a REPEAT-UNTIL). Why clutter up a simple mental template with a more complex representation of such a simple process. 3.) MACROS: The MODULE construct will eliminate the need for macros in *most* cases. This is fine and dandy for the cases it does cover, but what about the cases it doesn't? Since macros can be implemented quite inexpensively, and improve program efficiency, why not include them? 4.) POINTERS, BIT OPERATIONS, and SIGNIFICANT Blanks. Here people have already done most of the shelling for me. However, I have one suggestion on the issue of Significant blanks. If the "dusty deck" crowd needs blanks to be insignificant, then define a dialect for FORTRAN 8x that has identical to the final standard but where blanks are significant. Then it would be up to compiler developers to choose whichever dialect they wish to implement. Okay flames away! I shouldn't even be in this mess - I spend most of my time programming in PROLOG! Edouard Lagache lagache@violet.berkeley.edu
lamson@sierra.uucp (scott h lamson) (02/10/88)
lagache@violet.berkeley.edu (Edouard Lagache) writes > I am disturbed (to put it mildly) by some of the comments on why > some reasonably obvious features have been omitted from FORTRAN 8x. > Lets take a look at some of them: > 1.) INCLUDE: The standard reply is that by eliminating the need for > common blocks, one will eliminate the need for this statement - > huh? It is unreasonable to suppose that I might want to have a > header file of derived types, or symbolic constants, or macros The module facility of fortran-8x will provide access to derived types, parameters, and procedures as well as the equivalent of common blocks. Adding an INCLUDE as well would further complicate the language, not simplify it. Also INCLUDE's invite non-portability, as including a unix file name which is gibberish on an IBM. > 2.) WHILE: FORTRAN 8x contains looping constructs that are more > powerful than WHILE. So what? When I am trying to read in some > indefinite number of items from input, what I need is a WHILE loop > (or a REPEAT-UNTIL). Why clutter up a simple mental template with > a more complex representation of such a simple process. Maybe so... > 3.) MACROS: The MODULE construct will eliminate the need for macros in > *most* cases. This is fine and dandy for the cases it does cover, > but what about the cases it doesn't? Since macros can be > implemented quite inexpensively, and improve program efficiency, > why not include them? What can you do with macros that cannot be done with internal procedures? Is the additional complexity worth it? > 4.) POINTERS, Pointers greatly increase ambiguous data dependencies, making compiler optimization (especially for vector or parallel architectures) much less productive. Better to supply primitive operations (based internally on pointers) that the compiler can understand without the complete ambiguity pointers introduce. Fortran-8x seems to do this reasonably well with allocate and identify. Kind of like object-oriented pointers. >BIT OPERATIONS, I agree. The biggest sources of non-portable code (after programmers who use any extension in the book...:-) were character data in numeric arrays (addressed in fortran-77), lack of dynamic arrays (addressed in fortran-8x {proposed...}), system interface (usually just date/time etc. also addressed in 8x) and bit manipulations where required. I would like to see this included. and SIGNIFICANT Blanks. > If the "dusty > deck" crowd needs blanks to be insignificant, then define a > dialect for FORTRAN 8x that has identical to the final standard > but where blanks are significant. How about a much simpler approach. Require a FORTRAN-8x compiler to be accompanied by a filter that removes insignificant blanks. It also could convert the fortran-77 source format (col 6 = continue,...) to the fortran-8x format, so the compiler itself did not have to read both source code formats as the current proposed standard specifies. The new format uses & at the end of lines to mark the next line as a continuation, 132 columns, ;'s to put multiple statements on one line. > Edouard Lagache > lagache@violet.berkeley.edu Scott| ARPA: lamson@ge-crd.arpa Lamson| UUCP: lamson@sierra.steinmetz.ge.com (518)387-5795| GE DECnet: qtmvax::lamson Scott| ARPA: lamson@ge-crd.arpa Lamson| UUCP: uunet!steinmetz!sierra!lamson (518)387-5795| GE DECnet: qtmvax::lamson