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

mcdonald@uxe.cso.uiuc.edu (05/15/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 /


This is LEGAL FORTRAN. FORTRAN 66 and earlier, to be sure, but
legal nevertheless. I would be rather distressed if a compiler I
was considering buying would not compile it. I do not lightly
tolerate changes that break legal programs. Note the big flap over
proposals in Fortran 8x to POSSIBLY, maybe just CONSIDER deleting some
things in the far distant future (YES, NOT deleting them in Fortran
8x itself! And, this proposal was removed in the latest draft - but the memory
remains.)

Doug McDonald

khb%chiba@Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS) (05/16/89)

In article <50500128@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>
>
>was considering buying would not compile it. I do not lightly
>tolerate changes that break legal programs. Note the big flap over
>proposals in Fortran 8x to POSSIBLY, maybe just CONSIDER deleting some
>things in the far distant future (YES, NOT deleting them in Fortran
>8x itself! And, this proposal was removed in the latest draft - but the memory
>remains.)
>

Ah, the last committee was braver (or more naive, or foolish, or ??
:>) . They specifically DISALLOWED (made illegal) this "satanic"
usage.

So a properly complying X3.9-1978 compiler SHOULD not accept this code
... needless to say nearly all known compilers have been extended due
to market pressures ... :>




Keith H. Bierman      |*My thoughts are my own. Only my work belongs to Sun*
It's Not My Fault     |	Marketing Technical Specialist    ! kbierman@sun.com
I Voted for Bill &    |   Languages and Performance Tools. 
Opus  (* strange as it may seem, I do more engineering now     *)

mcdonald@uxe.cso.uiuc.edu (05/18/89)

>So a properly complying X3.9-1978 compiler SHOULD not accept this code
     Not true - properly complying compilers are allowed to
     take extensions to the language. This is an extension to F77.
>... needless to say nearly all known compilers have been extended due
>to market pressures ... :>

What you REALLY want is a compiler switch to require NO extensions.
Many compilers have this, or something close.

Doug McDonald

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

In article <105003@sun.Eng.Sun.COM> from khb%chiba@Sun.COM
(Keith Bierman - SPD Languages Marketing -- MTS), Keith
explains that Satanic character aliases were

>specifically DISALLOWED (made illegal) ...
>So a properly complying X3.9-1978 compiler SHOULD not accept this code

and that
>the last committee was braver (or more naive, or foolish, or ?? :>)

Let's say that the X3J3 committee exhibited sensibleness, acumen,
incisiveness, sagacity, short sightedness, adroitness, sageness,
prudence and some Byzantine shrewdness.

Speaking of which, Marketing Specialist Bierman goes on to say:
>... needless to say nearly all known compilers have been extended due
>to market pressures ... :>

Surely the X3.9-1978 standard reflected the consensus of the market!
Translated for the consumer, the marketing statement reads:  "We
didn't want to bother taking the old code out of our compilers,
besides if we provided consumers with a suitable filter, they might
migrate to another vendor.  The last thing we wish to do is
promote portability!"


In an electronic mail message from Greg Lindahl
<umbc3!uunet!bessel.acc.virginia.edu!gl8f>, Greg stated that Satanic
character aliases are "used by at least one big program that I know
of: AIPS, the Astronomical Image Processing System.  It consists of
3/4 million lines of code, and because it adheres to such an old and
outdated standard it has no trouble running on quite a few different
supercomputer, minisuper, and minicomputer architectures."

I have seen an impressive demonstration of what I think was the AIPS
software during a visit to the Space Telescope Science Institute in
Baltimore.  Just because astronomers measure events in light_years,
is not a good reason to allow AIPS to become obsolete.  How many
other programs contain these aliases?

Because a program adheres to an outdated standard is neither a
necessary nor sufficient reason to believe that it can be ported to
a particular computer.   Perhaps, AIPS would be a suitable test bed
for the development of a filter program that converts the Satanic
character aliases over to proper character type.  Another useful
filter would be one that replaces arithmetic if statements with
more structured control statements.

----------------------------------------------------------------------
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)
----------------------------------------------------------------------

khb%chiba@Sun.COM (chiba) (05/19/89)

In article <595@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM) writes:
....
>Translated for the consumer, the marketing statement reads:  "We
>didn't want to bother taking the old code out of our compilers,
>besides if we provided consumers with a suitable filter, they might
>migrate to another vendor.  The last thing we wish to do is
>promote portability!"

No. UNISYS, Harris, Lahey and others shipped compilers w/o this
"feature". All were forced to put it in by big users who said "if I
can't do this, I am buying someone else's machine" . Since DEC had
never disallowed it, it might be their fault... note that this
happened before Sun was born (for the most part) we're off the hook
(this time :>).
>
>In an electronic mail message from Greg Lindahl
><umbc3!uunet!bessel.acc.virginia.edu!gl8f>, Greg stated that Satanic
>character aliases are "used by at least one big program that I know
>of: AIPS, the Astronomical Image Processing System.  It consists of
>3/4 million lines of code, and because it adheres to such an old and
>outdated standard it has no trouble running on quite a few different
>supercomputer, minisuper, and minicomputer architectures."
>
....
>Because a program adheres to an outdated standard is neither a
>necessary nor sufficient reason to believe that it can be ported to
>a particular computer.   Perhaps, AIPS would be a suitable test bed
>for the development of a filter program that converts the Satanic
>character aliases over to proper character type.  Another useful
>filter would be one that replaces arithmetic if statements with
>more structured control statements.

AIPS is, in fact, very hard to port.



Cheers.
Keith H. Bierman      |*My thoughts are my own. Only my work belongs to Sun*
It's Not My Fault     |	Marketing Technical Specialist    ! kbierman@sun.com
I Voted for Bill &    |   Languages and Performance Tools. 
Opus  (* strange as it may seem, I do more engineering now     *)

gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) (05/19/89)

In article <595@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl) writes:

>In an electronic mail message from Greg Lindahl
><umbc3!uunet!bessel.acc.virginia.edu!gl8f>, Greg stated that Satanic
>character aliases are "used by at least one big program that I know
>of: AIPS, the Astronomical Image Processing System.  It consists of
>3/4 million lines of code, and because it adheres to such an old and
>outdated standard it has no trouble running on quite a few different
>supercomputer, minisuper, and minicomputer architectures."

Thank you for posting my mail verbatim without asking first. I often write
mail off the top of my head; before I post I double-check my information.
I am not associated with the AIPS people; I have used and installed some
older versions of AIPS

I do not know why the AIPS people put in Satanic characters in the
first place. However, checking my _Aipsletter_ vol 8 # 3, a magazine
published by the AIPS people, I find that they recently did convert
their Satanic characters into a different form. To quote: [with my
comments in brackets]

"  Unfortunately, not everything will be easy. Fortran 77 is weaker
than other modern languages in its handling of character strings, in
that they cannot occur with other data types in, for example, commons
and I/O records [ binary files ]. Thus, data structures such as the
AIPS header [ which contains character data and real data ] are not
allowed by the language definition. We are therefore required to
define a non-standard variable type called HOLLERITH to hold character
data within I/O records and commons. A few simple operations may be
done on HOLLERITH variables, but mostly they will be accessed only by
the two routines which convert between HOLLERITH and CHARACTER.  The
new AIPS uses CHARACTER variables essentially everywhere except for
storage in data structures and all the old [ Satanic ]
character/hollerith forms (1 or 2 per integer, or NCHPFP per floating)
are eliminated. The storage in HOLLERITH variables will be 4
characters per storage unit."

A preprocessor is used to convert HOLLERITH variables into whatever works
on a particular implementation. For most implementations, HOLLERITH can
be REAL -- Satanic characters strike again.

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. Remember, we're
talking Standard here: just because all the computers you use have the
non-standard extension that character and other types can coexist doesn't
mean that the Standard says so.

------
Greg Lindahl       |  Welcome to Mars, Earthling. We Martians don't like
gl8f@virginia.edu  |  illegal aliens, so we'll just have to deport you.

khb%chiba@Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS) (05/19/89)

In article <1515@hudson.acc.virginia.edu> gl8f@Virginia.EDU (Greg Lindahl) writes:

>If you can come up with an ANSI-Standard Approved Nutritious Scheme for
>writing character data into binary files with real numbers

?? 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.


Keith H. Bierman      |*My thoughts are my own. Only my work belongs to Sun*
It's Not My Fault     |	Marketing Technical Specialist    ! kbierman@sun.com
I Voted for Bill &    |   Languages and Performance Tools. 
Opus  (* strange as it may seem, I do more engineering now     *)

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

In article <1515@hudson.acc.virginia.edu> from
gl8f@bessel.acc.Virginia.EDU (Greg Lindahl), Greg protests:

>Thank you for posting my mail verbatim without asking first.
Greg, to you, I extend my most sincere apology.

>I often write mail off the top of my head; before I post I
>double-check my information.
Thank you for the flummery :-(

I hope the dialogue that flows from my unintentional breach of
etiquette will help identify the reasons why "Fortran 77 is weaker
than other modern languages in its handling of character strings, ..."

>...                checking my _Aipsletter_ vol 8 # 3, a magazine
>published by the AIPS people, I find that they recently did convert
>their Satanic characters into a different form.

That is good news.  How does one subscribe to _Aipsletter_?

>...                         just because all the computers you use
>have the non-standard extension that character and other types can
>coexist doesn't mean that the Standard says so.

Sigh, the SVS-fortran compiler I am using doesn't allow character
arrays or strings to exist in the same labeled common with integers
and reals; this rates a 6.31 in the demolition derby.  I would like
to be able to do something like the following:
      PARAMETER (KMAX=a_big_number)
      PARAMETER (JMAX=4*KMAX)
      COMMON /ARCHIV/ ARRAY
        INTEGER*4 IARRAY(KMAX)
        REAL*4 ARRAY(KMAX)
        CHARACTER*(JMAX) DNA
        CHARACTER*1 AND(JMAX)
        EQUIVALENCE (IARRAY,ARRAY,DNA,AND)
By using integer pointers, one could store or retrieve information
from a large archival record containing mixed types.  A simple
WRITE N, ARRAY should copy the whole record to an I/O device.
This allows a hacked dynamic storage scheme.   The only problem
is that it is not portable for many disparate reasons.

First, as the _Aipsletter_ points out, the standard doesn't allow
>"... character strings [... to] occur with other data types in,
>for example, commons and I/O records ... "
I have not encountered a computer that requires this separation
because of any hardware limitation.  Second, most implementations
severely limit the length of a character string.  Third, some
implementations limit the number of bytes that can be written to
a binary I/O record.

RM-fortran on an IBM PC/AT limits a binary write to 1032 bytes;
the XLA+ compiler on our AT&T 3B2 limits the length to 256 bytes.
This renders the binary write statement impotent and hence gets
rated at 3.87 in the demolition derby.  I think it was short
sighted of the X3J3 committee not to require implementors to
use spanned records as defined in ANSI X3.27-1978 (pages 24-26).
Don't the various ANSI committees communicate with each other?

----------------------------------------------------------------------
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)
----------------------------------------------------------------------

grandi@noao.edu (Steve Grandi) (05/22/89)

In article <595@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM) writes:
>
>I have seen an impressive demonstration of what I think was the AIPS
>software during a visit to the Space Telescope Science Institute in
>Baltimore.  Just because astronomers measure events in light_years,
>is not a good reason to allow AIPS to become obsolete.  How many
>other programs contain these aliases?

What you saw at STScI was almost certainly not AIPS but rather IRAF (Image
Reduction and Analysis Facility) which has been adopted by STScI to host
the Hubble Space Telescope reduction software STSDAS.  IRAF is a product of
the National Optical Astronomy Observatories and is optimized for optical
astronomy; AIPS is a product of the National Radio Astronomy Observatory
and is optimized for radio astronomy.

A brief plug.  The scientific portions of IRAF are programmed in a
high-level language that is preprocessed into FORTRAN (I don't know how
character aliases are handled).  The host system interface is written in C.
IRAF is running on several versions of Unix, VAX/VMS and AOS/VS; we have
exported IRAF systems to over 200 sites around the world. 

You can contact the IRAF project at iraf@noao.edu.  From the latest  AIPS
letter, try aipsmail@nrao.edu for questions on AIPS.

Don't you just love acronyms!
-- 
Steve Grandi, National Optical Astronomy Observatories, Tucson AZ, 602-325-9228
UUCP: {arizona,decvax,ncar}!noao!grandi  or  uunet!noao.edu!grandi 
Internet: grandi@noao.edu             SPAN/HEPNET: NOAO::GRANDI (NOAO=5355)

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

In article <87@unmvax.unm.edu> from brainerd@unmvax.unm.edu
(Walt Brainerd), Walt writes:
>As usual, there are two sides to the coin.
I'd like to see the other side of that coin; I think the game is
rigged--pure bunco!

>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.
_BUT NOT PORTABLE!_  Why not just call you experiment HAL-2001?

>The standards  committee is attacked frequently for "inventing new
>stuff" (it usually is not put this politely).
I have seen evidence of some NRA-like attacks organized by certain
vendors; the selfsame "experimentalist" dead set on preventing the
language from being truly portable.

>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.
Like the muddled why that the character type has been implemented,
or the short sighted way that the binary write statement was specified
or the gross omission of the DO ...  ENDDO control loops, or ...  
I think that the _Standards Organization_ must retain absolute control
over the language to provide adjudication of implementation disputes
and to promote timely enhancements to the language.  Furthermore, it
is important to protect the vendors from consumer pressure.  The
standards committee not the vendors must be responsive to market
pressures--that is, if we want a _portable_ standard.

>Nice examples of extensions that didn't come primarily from major
>vendors occurred in the multitude of preprocessors in the 1970s.
I think that preprocessors are excellent tools.  CLEAN77 looks to be
an useful preprocessing filter program.   I frequently execute one
or more edit macros to filter the nonstandard clamjamfry you appear to
be pandering.  I have occasionally used RATFOR.  I make extensive use
of the C language CPP preprocessor to handle the insertion of "INCLUDE"
code snippets, to provide conditional insertion of processor specific
features of the target system, and to use #define for token replacement
to effectively equivalence symbolic names to the dummy arguments of a
subroutine [See  Hybl (1987) _Fortec Forum_ Vol 6, No 6 Pages 10-11].
NONE OF THESE OPERATIONS REQUIRE SECTIONS 1.3.2.(4) OR 1.4 TO MAKE
THEM LEGAL.

>Their existence allowed me to argue (successfully, of course) for
>putting the IF...ELSE IF..ELSE.. END IF into Fortran 77.  Otherwise,
>it would not be there now.
Thanks.  But why did X3J3 insert the suicide gene?  Sections
1.3.2.(4) and 1.4 guarantee that the objective of portability will
never be achieved!

----------------------------------------------------------------------
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/24/89)

In article <597@mbph.UUCP>, hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM) writes:
> 
> _BUT NOT PORTABLE!_  Why not just call you experiment HAL-2001?

Because they are based on and utilize the huge investment in Fortran libraries
and programmer training.

> Like the muddled why that the character type has been implemented,
> ...
> or the gross omission of the DO ...  ENDDO control loops, or ...  

The character data type (as added to F77) was one example where it was
_not_modeled on widespread implementations (but that does not necessarily
make it bad or good, of course).

> I think that the _Standards Organization_ must retain absolute control
> over the language to provide adjudication of implementation disputes
> and to promote timely enhancements to the language.

But who controls the Standards Organization?  Right now X3J3 is about 50%
vendors, but at different times and for different languages, this
figure could vary widely.  Right now, for Fortran, about two-thirds
of the vendor's representatives have been on the committe less than
three years.  Do you really want _your_ language completely controlled
by a committee with this kind of makeup?  Or do you want it controlled
by a bunch of pointy-headed academicians who know nothing about the
"real" world (some members of X3J3 have been accused of being such).

> ... The
> standards committee not the vendors must be responsive to market
> pressures--that is, if we want a _portable_ standard.

One thing the vendors the vendors should understand better than
anyone else is market pressure

>  ... 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.

I think Hybl has very good points and I don't necessarily disagree with
them; I was just trying to explain why others have a different
point of view.

Now for the bad news if you don't like nonportable things in a standard.
Last week X3J3 voted that the user can specify what the character set
(perhaps to include Greek letters or an a umlaut, for example)
is to be in a way that is processor dependent and use these characters
in a subroutine name, for example.  As was pointed out, this already
can be done as a processor extension, so it provides the programmer
nothing new, but now the processor does not have to flag it as
nonstandard (and nonportable) because it is in the standard!
Don't blame me for this one; I wansn't there.