[comp.lang.fortran] Character aliases are Satanic extensions

hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (05/10/89)

        I am converting a set of programs containing a total of about
60,000 line of "standard" fortran code written for a VAX computer.  The
following is typical of several hundred diagnostics I have encountered:

      DOUBLE PRECISION   NAME,NAMA,JTYPM,ISPEC
      DATA   IDNA,IRNA,ISPEC/4HD   ,4HR   ,8H$SPECIAL /

   98. *********** DATA IDNA,IRNA,ISPEC/4HD   ,4HR   ,8H$SPECIAL / <=== 
       ***** Error number 78 in line 98 of file nucgen.for *****
       ***** Type conflict in DATA statement *****

VMS fortran allows a user to enter character data typed as logical,
byte, integer, real, double precision, dimension, probably complex and
the proper character type "character."  VMS fortran allows character
data to be assigned to these alias types by arithmetic assignment or by
a data statement or non character functions or by using the read
statement.

The use of these Satanic extensions by the VMS implementation of Fortran
scores a 9.73 in the Fortran demolition derby; it is a robust attempt to
demolish the concept of typing!  My compiler quite logically expects
character data to be typed "character."  It is real shame that FORTRAN
is not a standardized language!

Being philosophical about this, I am reminded of the opening words in
"The Tale of Two Cities" by Charles Dickens:  "It was the best of times,
it was the worst of times, ..."   VMS fortran is the best of
compilers, it is the worst of compilers; a language standard is
intended to promote portability, it is intended to promote
profitability, ...

The VAX implementation gives new meaning to the term garbage collection.
Mixing good standards with bad and ugly non standard statements
scrounged from old compilers is an example of misoneism.  It will
compiles everybodies old code.  The basic idea is valid; however,
the incorporation of the garbage collector in a standards conforming
compiler is not.  What is needed is an Exorcist section appended to
the standard.  For example, I could have used an exorcism that
retyped the logical, real, double precision, and byte aliases for
character variables as truly character--not an easy task.  The
Exorcist should produce a new source deck.  

I think that it would be easier to depreciate old features from
a language if an Exorcist existed to do the job; especially a
public domain Exorcist.

----------------------------------------------------------------------
Albert Hybl, PhD.              Office UUCP: uunet!mimsy!mbph!hybl
Department of Biophysics       Home   UUCP: uunet!mimsy!mbph!hybl!ah
University of Maryland                CoSy: ahybl
School of Medicine
Baltimore, MD  21201                 Phone: (301) 328-7940 (Office)
----------------------------------------------------------------------

weyrich@csun1.UUCP (Orville Weyrich) (05/11/89)

From article <592@mbph.UUCP>, by hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM):
> VMS fortran allows a user to enter character data typed as logical,
> byte, integer, real, double precision, dimension, probably complex and
> the proper character type "character."  VMS fortran allows character
> data to be assigned to these alias types by arithmetic assignment or by
> a data statement or non character functions or by using the read
> statement.
> 
> The use of these Satanic extensions by the VMS implementation of Fortran
> scores a 9.73 in the Fortran demolition derby; it is a robust attempt to
> demolish the concept of typing!  My compiler quite logically expects
> character data to be typed "character."  It is real shame that FORTRAN
> is not a standardized language!

What you describe was correct FORTRAN-66, before a character data type existed.
The VMS compiler would probably reject the program if you used the
/STANDARD switch on the compiler.  FORTRAN is a permisive standard that
stresses what is required to be supported. It does not prohibit the support
of extensions or anachronisms as long as they do not directly conflict
with required features.

I agree that a filter program that removes anachronisms would be nice, and I
have played around with such things.  But it is not an easy task. Consider
for example one old program that I had the misfortune (more positively, the
experience :-) of porting: It had an array of double precision values which
was used for a symbol table.  Some elements of the array stored character
data and other elements stored double precision values. No way that that
program could be redone using only standard FORTRAN-77 without completely
rewriting the symbol table code (and this code was developed when the
idea of data abstraction and information hiding etc. was not in vogue :-( ).

Another problem is that automatic conversions often obfusacate the code even
worse than it already is.  For example, how would you translate arithmetic
IF's, computed GOTO's, and assigned GOTO's without adding still more goto's
and more IF ELSEIF ELSE statements?

On the other hand, I would expect that it would be very easy to write a
filter that "tokenized" FORTRAN source code so that a future revision of
FORTRAN could do away with the archaic "blanks not significant" syntax.
Unfortunately, this might break some existing preprocessors. You can't
please everyone.
-- 
Orville R. Weyrich, Jr.          | UUCP    : ...gatech!csun1!weyrich
Department of Computer Science   | INTERNET: weyrich@csun1.cs.uga.edu
University of Georgia            |
Athens, GA 30602 USA             | MA BELL : (404) 542-1082

hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (05/13/89)

From article <177@csun1.UUCP> by weyrich@csun1.UUCP (Orville Weyrich):
> What you describe was correct FORTRAN-66, ...  FORTRAN is a permissive
> standard that stresses what is required to be supported. It does not
> prohibit the support of extensions or anachronisms as long as they do
> not directly conflict with required features.

The ANSI X3.9-1978 FORTRAN language standard is explicit in
the definition of integer, real, double precision and character
types.  Nowhere in the X3.9 standard is there any hint that
integer, real or double precision variables can serve as character
aliases.  Indeed, to do so would directly contravene the type
definitions.  The standard has been in place for more than ten year.
The character type statement was intended to supplant the multitude
of aliases used in the then existing FORTRAN compilers.  Do you think
that the following program will will produce the answer:  '120_miles' ?
It compiles without diagnostics on a VAX! :-(

      double precision distance, time, speed
      time='2_hours'
      speed='60_mph'
      distance=time*speed
      print *, distance
      end

The programs I am porting bear dates 1984-1986 not 1974.  Perusal
of the colorful VAX VMS FORTRAN Language Reference Manual divulges
a description _with examples_ on how to use the Satanic character
aliases.  The description is not relegated to an appendix nor does
it discourage the continued use of such coding.  The implementors
of the VAX VMS FORTRAN should be excoriated for promoting the
perpetuation of such anachronistic coding practices.

The _NEW WORLD DICTIONARY_ defines "standard" as (1) any figure
or object, esp, a flag or banner, used as an emblem or symbol of
a leader, people, military unit, [fortran language implementor],
etc ... (2) something established for use as a rule or basis of
comparison in measuring or judging capacity, quantity, content,
extent, value, quality, [portability, readability, maintainability] ...

Do you think that the second definition applies to the X3.9
FORTRAN language standard?  Then read the following snippet.
It was carefully crafted by the acolytes of Mammon.  Although
it provides me with the opportunity to rate different FORTRAN
implementations in a demolition derby, it is the cause of the
poor portability of FORTRAN programs.  The X3J3 committee scores
a perfect 10.00 for allowing implementors to add his/her flag
to their products.  Have you tried to install a VWvan wheel or glow
plug on an International Harvester Travelall?

: 	1.3.2. _Exclusions_.  This standard does not specify:
: 	    [...]
: 	  (4) The results when the rules of this standard fail
: 	      to establish an interpretation.
: and:
: 	1.4. _Conformance_
: 	  [...]
: 	A processor conforms to this standard if it executes
: 	standard-conforming programs in a manner that fulfills the
: 	interpretations prescribed herein.  A standard-conforming
: 	processor may allow additional forms and relationships
: 	provided that such additions do not conflict with the
: 	standard forms and relationships.  [...]

>I agree that a filter program that removes anachronisms would be
>nice, ...  But it is not an easy task. ...

Would it be challenging as a computer science project?  I think
I would like to see several user selectable exorcisms.  They should
be written in a portable language--like C, awk, SNOBOL or ICON :-)/2

----------------------------------------------------------------------
Albert Hybl, PhD.              Office UUCP: uunet!mimsy!mbph!hybl
Department of Biophysics       Home   UUCP: uunet!mimsy!mbph!hybl!ah
University of Maryland                CoSy: ahybl
School of Medicine
Baltimore, MD  21201                 Phone: (301) 328-7940 (Office)
----------------------------------------------------------------------

brainerd@unmvax.unm.edu (Walt Brainerd) (05/13/89)

In article <594@mbph.UUCP>, hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM) writes:
> ...  The X3J3 committee scores
> a perfect 10.00 for allowing implementors to add his/her flag
> to their products.
> 
> : 	1.3.2. _Exclusions_.  This standard does not specify:
> : 	    [...]
> : 	  (4) The results when the rules of this standard fail
> : 	      to establish an interpretation.
> : and:
> : 	1.4. _Conformance_
> : 	  [...]
> : 	A processor conforms to this standard if it executes
> : 	standard-conforming programs in a manner that fulfills the
> : 	interpretations prescribed herein.  A standard-conforming
> : 	processor may allow additional forms and relationships
> : 	provided that such additions do not conflict with the
> : 	standard forms and relationships.  [...]
> 
As usual, there are two sides to the coin.  These items have been
present in the Fortran standards from the beginning for very good reasons.
It allows implementors (not just IBM and DEC, but people doing all kinds
of experimental projects into which they want to embed Fortran) to add
things to the language and still be standard.  The standards committee
is attacked frequently for "inventing new stuff" (it usually is not put
this politely).  This extension scheme allows "new stuff" to be tried out
in real implementations providing a better chance of getting it right when
it is standardized.  Nice examples of extensions that didn't come primarily
from major vendors occurred in the multitude of preprocessors in the 1970s.
Their existence allowed me to argue (successfuly, of course) for putting
the IF...ELSE IF..ELSE.. END IF into Fortran 77.  Otherwise, it would not
be there now.

Of course, this puts the burden on the programmer to know what is
standard and what is portable, but vendors are getting a little better
about shading nonstandard things in their manuals.

To help balance things a bit, the proposed 8x says a processor must contain
"the ability to detect and report the use within a submitted program unit
of an additional form or relationship that is not permitted
by the numbered syntax rules or their constraints."  Also a processor
must have the capability of detecting obsolescent features.  How this is
done is _not_ specified; presumably it will be with a compiler option.

seibel@cgl.ucsf.edu (George Seibel) (05/13/89)

In article <594@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM) writes:

]From article <177@csun1.UUCP> by weyrich@csun1.UUCP (Orville Weyrich):
]> What you describe was correct FORTRAN-66, ...  FORTRAN is a permissive
]> standard that stresses what is required to be supported. It does not
]> prohibit the support of extensions or anachronisms as long as they do
]> not directly conflict with required features.
]
][the following] compiles without diagnostics on a VAX! :-(
]
]      double precision distance, time, speed
]      time='2_hours'
]      speed='60_mph'
]      distance=time*speed
]      print *, distance
]      end
]
]The programs I am porting bear dates 1984-1986 not 1974.  Perusal
]of the colorful VAX VMS FORTRAN Language Reference Manual divulges
]a description _with examples_ on how to use the Satanic character
]aliases.  The description is not relegated to an appendix nor does
]it discourage the continued use of such coding.  The implementors
]of the VAX VMS FORTRAN should be excoriated for promoting the
]perpetuation of such anachronistic coding practices.

Well, Al, I gotta come clean here.   The Satanic program came out
of our lab here at UCSF.   Quite some while ago, I suggested in a
group meeting that we dump the Hollerith stuff.   The response was
(a now infamous quote) "Hollerith was a great man.  He should be
honored".   Along with some laughter.   What this really meant was
that no one felt like going through 40000 lines of code and doing it.
Some of the code dates back to the FORTRAN 66 days, and that's why it
looks the way it does.   The '84-86 dates were just revisions.

I fully agree with you that the DEC VMS Fortran compiler is responsible
for some real porting headaches.  When the orange manual actively
encourages the use of extensions, many of which have functional ANSI
equivalents, it is pretty clear to me that DEC hopes to keep you as
a customer.   Nearly ALL compilers are extended in a variety of subtle
ways.  This is understandably done because quite frankly the market demands
it.   I do wish, however that vendors would clearly mark their language
manuals to indicate which language constructs are nonstandard.  Some
vendors (e.g. Cray) do this.  This to me is an indication of the high
ethical standard of that firm.

BTW, if you're willing to wait a couple of months, I'll be releasing
a new revision of Amber with avoidable machine dependencies removed.
The unavoidable ones will be well isolated.  The remaining Hollerith
data will be of a form that most compilers will swallow (no guarantees,
though - I don't get paid for this).
  And yes, I'll even fix the Satanic Nucgen :^)

George Seibel, UCSF

hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (05/30/89)

In article <92@unmvax.unm.edu> from brainerd@unmvax.unm.edu (Walt
Brainerd) writes:
>> ... The
>> standards committee not the vendors must be responsive to market
>> pressures--that is, if we want a _portable_ standard.
>
>One thing the vendors should understand better than
>anyone else is market pressure
>
One thing the Army knows better than anyone else is warfare,
but they are not allowed to declare WAR.  One thing the our police
know better than anyone else is crime, but they are not allowed to
write criminal law.  One thing that vendors could do is assist clients
lobby the Standards Organization rather then running a NRA-like campaign
for their own sub rosa agenda.

>>  ... Sections
>> 1.3.2.(4) and 1.4 guarantee that the objective of portability will
>> never be achieved!
>
>It can be achieved only (in the case of Fortran) by intelligent
>programmers sticking to standard code with the help of the (new
>in Fortran 8x) requirement on the processor to flag nonstandard
>syntax, when requested to do so, and help in the form of shading
>of nonstandard stuff in the vendor's manuals.
>
This is an excellent example of a calumniatory sentence.  Notice
the innuendo--ONLY STUPID PROGRAMMERS USE VENDOR EXTENSIONS!
Those who crafted and espouse that statement want FORTRAN programmers
to engage in internecine name calling.  Let me restate:  "Perusal
of the colorful VAX VMS FORTRAN Language Reference Manual divulges
a description _with examples_ on how to use the Satanic character
aliases.  The description is not relegated to an appendix nor does
it discourage the continued use of such coding.  The implementors
of the VAX VMS FORTRAN should be excoriated for promoting the
perpetuation of such anachronistic coding practices."  Those who
provided the programs I am porting should not interpret my pasquinading
of the X3.9-1978 FORTRAN language standard in any way a criticism of
their programming technique.

In article <3728@s.cc.purdue.edu> from ags@s.cc.purdue.edu 
(Dave Seaman), writes:
>Old-timers may recall that around 30 years ago, a satirical work
>known as "The Computer Programmer's Coloring Book" was popular.
>
>On one of the pages was a picture of a stick man, with the caption:
>
>	This is a FORTRANner.  Color him naive.
>
Are you vaccinia naive?  Let me rephrase:--Have you ever been given
a smallpox vaccination?  The objective of vaccination is to provide
immunity to a specific disease by causing the formation of antibodies.
Immunity can also be acquired by contracting and surviving an attach
by the disease.

Thirty years ago I was a naive FORTRANner working as a Post Doctoral
student at Iowa State University.  Programmers zealously tried to
economize memory or reduce execution time.  IBM provided FORTRANners
an extension call Symbolic Assembly Procedures.  By putting an "S" in
column one, we could include a machine language instruction in-line
along with a symbolic reference to an appropriate variable.  That was
a terrific idea.  Symbolic Assembly Procedures invaded our code like
a retrovirus attaching its victim.  After about a year, Iowa State
University acquired a new computer; its FORTRAN compiler did not
provide Symbolic Assembly Procedures.

The sudden withdrawal was painful and accompanied by distressing 
side effects; I woke up to the fact that IBM had made a _SAP_ of
me.  That is how I acquired the misoextension antibodies that help
protect me against vendor extensions.  I hope my experience will
help others to understand why FORTRAN should be a portable language
and not a plethora of vendor experiments.

----------------------------------------------------------------------
Albert Hybl, PhD.              Office UUCP: uunet!mimsy!mbph!hybl
Department of Biophysics       Home   UUCP: uunet!mimsy!mbph!hybl!ah
University of Maryland                CoSy: ahybl
School of Medicine
Baltimore, MD  21201                 Phone: (301) 328-7940 (Office)
----------------------------------------------------------------------

hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (05/31/89)

In article <592@mbph.UUCP> from hybl@mbph.UUCP (Albert Hybl) writes
]I am converting a set of programs containing a total of about
]60,000 line of "standard" fortran code written for a VAX computer.
]
While in article <11596@cgl.ucsf.EDU> from seibel@cgl.ucsf.edu,
(George Seibel) writes
>Well, Al, I gotta come clean here.   The Satanic program came out
>of our lab here at UCSF.   Quite some while ago, I suggested in a
>group meeting that we dump the Hollerith stuff.   The response was
>(a now infamous quote) "Hollerith was a great man.  He should be
>honored".   Along with some laughter.  ... 
>I fully agree with you that the DEC VMS Fortran compiler is responsible
>for some real porting headaches.
>
George, I did not say and do not think that AMBER is Satanic.  Indeed,
I think it is an important contribution applicable to the study of
molecular structure.  I am infuriated because the X3.9-1978 standard
has failed to provide us with a portable computer language and the
tools with which to filter obsolete features.  My quixotic rebuke
was intended to be directed at the suicide clauses in the X3.9-1978
standard and the unhelpful contributions from the vendors.

> ...                                       What this really meant was
>that no one felt like going through 40000 lines of code and doing it.

Hmmm, why do I count 60,000 lines?  The following table lists the
subdirectories of Amber along with the line count for the source code
files (*.ftn), the #include files (*.h) and the Makefiles.  Where
do we differ?

                 *.ftn    *.h  Makefile
          anal    8072     24     91
          dmin    5130     23     86
          dyn     6182     38     89
          edit    4825     67     85
          etc     1592      7     77
          link    2748     94     77
          mdanal  8923    131     85
          min     5503     32     93
          nmode   4489     17     60
          parm    2685    119     68
          pol     4910     37     75
          prep    2986     41     66
          ==========================
                 58045    630    952
          Total  59627 ~ 60,000

>BTW, if you're willing to wait a couple of months, I'll be releasing
>a new revision of Amber with avoidable machine dependencies removed.

Now you tell me--I've already converted most of it into a more portable
format.  

----------------------------------------------------------------------
Albert Hybl, PhD.              Office UUCP: uunet!mimsy!mbph!hybl
Department of Biophysics       Home   UUCP: uunet!mimsy!mbph!hybl!ah
University of Maryland                CoSy: ahybl
School of Medicine
Baltimore, MD  21201                 Phone: (301) 328-7940 (Office)
----------------------------------------------------------------------

brainerd@unmvax.unm.edu (Walt Brainerd) (05/31/89)

In article <598@mbph.UUCP>, hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM) writes:
> 
> One thing the Army knows better than anyone else is warfare,
> but they are not allowed to declare WAR.
> 
True, but maybe not relevant. If you are trying to make an analogy
with the Fortran standards activity, you would be proposing
that generals not sit on councils that advise people who declare war.
Are you proposing that no vendors be allowed on standards committees?
I don't see any way that could happen under our
current system of standards making by ANSI, although, given what has
happened to X3J3 over the last few years, it seems tempting.
These years have convinced me that something should change, but
I am not sure I have any specific proposals that are politically feasible.
Would love to hear some.

Incidentally, some of the vendors on X3J3 have been very supportive
of the efforts and have made execellent contributions to the technical work.

> This is an excellent example of a calumniatory sentence.  Notice
> the innuendo--ONLY STUPID PROGRAMMERS USE VENDOR EXTENSIONS!

Wrong!
IGNORANT programmers also use vendor extensions (there is a lot of
difference).  Also INTELLIGENT programmers use extensions
when they need them to get a special job done.  I believe there are some
very useful things that do not belong in the standard (one reason
being that they are not portable).  Perhaps the user-defined character
facility I mentioned previously is a good example.  It is useful
to certain groups of programmers, but is _not_ portable, and therefore
does not belong in the standard.

We seem to have two proposals (please don't anyone say these are MY proposals):

1)  No vendors should be allowed on standards committees.
    If there is some more mellow variation of this,
    that might be interesting to hear.

2)  The Fortran standard should state that the processor does not
    conform to the standard if it accepts extensions.

I would like to see some rational discussion of these issues by other
readers of these items.  Another point to keep in mind is that adoption
of (2) means that the standard would not be upward compatible with
the previous standard.  Remember what happened when we tried to schedule
deletion of some important redundant features for the year 2030?

Walt Brainerd   brainerd@unmvax.unm.edu   505/275-0800

usenet@saturn.ucsc.edu (Usenet News Account) (05/31/89)

Organization: University of California, Santa Cruz;  UCO/Lick Observatory
Keywords: Compiler Warning Messages
From: mongo@helios (Mongo Package)
Path: helios!mongo

In article <100@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes:
>In article <598@mbph.UUCP>, hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM) writes:
>> the innuendo--ONLY STUPID PROGRAMMERS USE VENDOR EXTENSIONS!
>IGNORANT programmers also use vendor extensions (there is a lot of
>difference).  Also INTELLIGENT programmers use extensions ....
>We seem to have two proposals (please don't anyone say these are MY proposals):
>1)  No vendors should be allowed on standards committees.
>2)  The Fortran standard should state that the processor does not
>    conform to the standard if it accepts extensions.

If the Fortran 8x standard ends up *requiring* that a Fortran compiler be
able to generate Warning messages, then things are headed in the right
direction.  With such warnings, anyone who writes code that might ever
be compiled by a different compiler can know about it.  I would even prefer
it if the warnings were ON by default.

I make rather liberal use of the non-standard "include" statement in FORTRAN
77.  I do this knowing that I would write a Pre-Processor to duplicate the
"include" functionality if I were using a compiler which did not have it.
The utility of "include" to me is sufficient that I would not mind having
to watch Warning statements roll past on the screen.  I prefer to think that
this does not make me STUPID or IGNORANT.

Finally, I personally think that any Fortran/FORTRAN compilers that accept
Hollerith should be required to *ALWAYS* print a warning message.  When
an extension has been specifically DISALLOWED, the programmers should be
forced to notice this Every Time the code is compiled.  Vendors should look
upon this as providing a service.

Steve Allen
No, my employer may not share these opinions.

hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (06/01/89)

In article <1515@hudson.acc.virginia.edu> from
gl8f@bessel.acc.Virginia.EDU (Greg Lindahl), "A challenge"
>If you can come up with an ANSI-Standard Approved Nutritious Scheme for
>writing character data into binary files with real numbers, or putting
>character data into commons with other data, let me know. ...

]khb%chiba@Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS)
]in message <105811@sun.Eng.Sun.COM> responds:
]?? this is perfectly allowed; viz.
]	write(10) character*10,real*8,character*10
]is legal in x3.9-1978.
]
], or putting
]>character data into commons with other data, let me know
]
]this (and equivalence) is what was disallowed.
]

From the porting trenches, let me ask:  can we read/write character
information to and from a real array?  First, let's answer: WHY
DO IT?  Scientist use names for the molecules with which they're
working; they attach names to the residues from which the molecules
are built; they assign names to the the atoms from which the residues
are built; they identify the atom type with a atomic symbol.  Because
of the unpredictable size of a problem, the authors of the programs
I am porting implemented a dynamic storage scheme that uses two large
arrays--one REAL*4 and the other INTEGER*2.  Since many of the names
are four characters long, they were stashed into the REAL*4 array along
with the atomic coordinates and all the other real REAL parameters.
Ok, now lets see how this can be done without rewriting the dynamic
storage scheme and without choking a standards conforming compiler.

Let's try:
      CHARACTER*4 NAME
      REAL X(10)
      NAME = 'Na+ '
      OPEN (UNIT=10,FORM='UNFORMATTED',FILE='F10',STATUS='NEW')
      WRITE (UNIT=10) NAME
      REWIND (UNIT=10)
      READ (UNIT=10) X(4)
      WRITE (*,FMT='(1X,A4)') X(4)  ! Probably not standard and
* is used here only for testing.
      CLOSE (UNIT=10,STATUS='DELETE')
      END

This is, of course, an over simplified example.  The binary write
could be in a different program unit or a different program from the
unit that does the binary read.  The binary file is not portable
between differing hardware types but is the source code? My SVS-fortran
compiler think it's ok.  The binary WRITE has expunged the character
identification from the variable NAME; it becomes just a bit string.
If the length of the bit string is compatible with the length of a
REAL*4 variable, the READ binary stashes the bits into the REAL
array element.  -- We did it -- Right ??? .... 

Maybe not--from a private communication, I learned that there
exists hardware specifically designed for floating point operations.
Certain floating point registers will immediately normalize
the values loaded into them because that is what they were
designed to do.  NORMALIZATION OF A REAL VARIABLE CONTAINING
STASHED CHARACTER INFORMATION CAN DESTROY THE CHARACTER DATA!
The FORTRAN compiler can be written to suppress the use of
these registers when no floating point calculations are
specified thus allowing a programmer to move character data
around by using REAL or DOUBLE PRECISION variables.  But will
the next compiler you use be so thoughtful?

The moral is:  DON'T USE CHARACTER ALIASES!

----------------------------------------------------------------------
Albert Hybl, PhD.              Office UUCP: uunet!mimsy!mbph!hybl
Department of Biophysics       Home   UUCP: uunet!mimsy!mbph!hybl!ah
University of Maryland                CoSy: ahybl
School of Medicine
Baltimore, MD  21201                 Phone: (301) 328-7940 (Office)
----------------------------------------------------------------------

hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (06/01/89)

In article <597@mbph.UUCP> from hybl@mbph.UUCP (Albert Hybl)
I sited the following reference:
>[See  Hybl (1987) _Fortec Forum_ Vol 6, No 6 Pages 10-11].
                                            ^
                                            |_ wrong
The reference should read:
>[See  Hybl,A. (December 1987) _Fortec Forum_ Vol 6, No 3 Pages 10-11].

Sorry.
----------------------------------------------------------------------
Albert Hybl, PhD.              Office UUCP: uunet!mimsy!mbph!hybl
Department of Biophysics       Home   UUCP: uunet!mimsy!mbph!hybl!ah
University of Maryland                CoSy: ahybl
School of Medicine
Baltimore, MD  21201                 Phone: (301) 328-7940 (Office)
----------------------------------------------------------------------

zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) (06/01/89)

Real/double precision/complex types are susceptable to normalization
but integer ones are not, i.e. if you really must store characters in
noncharacter types use integer type.

On the other hand the integer size is implementation dependent, so
doing the above is nonportable (there are machines with 2,4,6,8,10,..
etc bytes per integer).

It is exactly for the latter reason that the CHARACTER type is
invented. It pushes implementation part of the problem onto the compiler
writer, so the source does appear implementation independent, i.e.
portable (e.g. CHARACTER*11 will always behave as storing 11 characters
regardless of the underlying word size).
--
___________________________________________________________________
Zdenko Tomasic, UWM, Chem. Dept., P.O. Box 413, Milwaukee, WI 53201
UUCP: uwvax!uwmcsd1!uwmcsd4!zdenko
ARPA: zdenko@csd4.milw.wisc.edu