[comp.lang.fortran] Gripes on missing FORTRAN-8x features.

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