Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 90 status
Message-ID: <5807@goanna.cs.rmit.oz.au>
Date: 17 May 91 09:28:35 GMT
Article-I.D.: goanna.5807
References: <3246@travis.csd.harris.com> <1991May10.002337.22669@ariel.unm.edu> <23881@lanl.gov>
Distribution: comp
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 31

In article <23881@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes:
> 8) ASSIGN statements with FORMAT labels.
> 
>    It's not clear why they chose to make this a separate issue from point
>    (7).  In this case, it is clear that CHARACTER variables (and POINTERs
>    to such) are exact replacements semantically - just a different syntax.
>    I have never needed to do this, but those who do can get by without the
>    ASSIGN just fine.

I have two observations to make about this.
The first is that I was rather surprised, looking at a supersonic flow
code written *recently*, to see that it was full of ASSIGNs.  It turned
out that they were all "ASSIGN statements with FORMAT labels".
The second is that CHARACTER variables are _not_ exact replacements,
although a smart Fortran compiler _could_ notice this special case.
What's the difference?  Well, a compiler can _check_ a FORMAT statement
at compile time, and can even generate code for it.  Using ASSIGN with
FORMAT labels ensures that you are _not_ passing to READ or WRITE any
formats that the compiler hasn't had a chance to look at.  This _can_
buy you safety (compile-time check) and speed (the format being compiled,
not interpreted at run time).  Now, a Fortran compiler should be keeping
around use/def information, so that when it says CHRVAR='(...)' it could
say "hmm, it's guaranteed that the next use of this variable is as the
format argument of an I/O statement, so I'll check now that the literal
is a valid format, and I'll even generate code for it."

This is what the C people call "a quality-of-implementation issue".
It _can_ be done, and it shouldn't even be hard, but _will_ it be done?

-- 
There is no such thing as a balanced ecology; ecosystems are chaotic.