Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.fortran
Subject: Re: dpANS Fortran 8x
Message-ID: <18237@mimsy.UUCP>
Date: 23 Jun 89 07:19:45 GMT
References: <1536@uw-entropy.ms.washington.edu> <13949@lanl.gov>
Reply-To: chris@mimsy.umd.edu.UUCP (Chris Torek)
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 63

[another `usa' distribution bites the dust]

In article <13949@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
[paraphrased:] Pointers are to data flow as `goto' is to control flow.

(A very reasonable analogy.  Many compilers reduce all `high level'
control constructs to gotos, then rebuild the high level constructs
in order to do control flow analysis, which is a necessary precursor
to data flow analysis.  Data flow analysis is a sufficiently harder
problem to preclude this approach, as yet.)

>I think that RANGE and IDENTIFY are _MUCH_ better at array sectioning
>than the present POINTER proposal is.  For recursive data structures
>I think that they should be provided as just that: recursive structures
>without explicit pointers required.  Aside from these, I can't think
>of any other need for pointers.  I think that Fortran should not have
>pointers introduced.

Well said.

The problem---and one should understand here that I am not really
arguing for one standard over the other: I think either one would be
premature---is this:  When designing a new language, it is very hard to
forsee what will be needed, what will be wanted, and what will simply
be excess baggage.  Both Pascal and C have `high level' control flow
constructs (while, etc).  But both also have `goto'.  (C has a weak
syntatic form; the nonlocal goto is done as a library routine.) The
goto---even the nasty nonlocal form---turns out to be good for rare but
important things like exception handling.  Now, one can always design a
new language that includes exceptions, but it happens to be a good
thing that no one standardised the `goto-less' form before effectively
forcing people to write in an incomplete language.  It is unfortunate
that they did standardise Pascal (e.g.) before noting the need for
conformant arrays.  Or, again in re C: before V7, C did not have the
`long' data type, nor did it have `union'.  They were not necessary, in
that they could be done with `struct', but they did turn out to be
convenient.

Applied to F8x, this might tempt one to throw in both forms:  RANGE,
IDENTIFY, and recursive data structures; *and* POINTER.  This is a
tempting road, but at its end lies something worse than PL/I.  The art
of language design lies in choosing the proper balance of power and
economy.  I, for one, do not believe that this line can be drawn
politically.  I am not even sure it can be drawn technically
---certainly not now, and not for the forseeable future.  (By
`technically' I mean quantitative analysis of the interactions of
various language features, as opposed to `gut feel' and/or
experimentation.)

All of this is why I always fear for the outcome of any ANSI or ISO
`standardisation'---all the more so when the `standard' comes to
inventing a new language.  (If you do not believe the F8x committee
is inventing a new language, well, never mind.  All language features
interact: sometimes very little, but sometimes very subtly.  Even
the tiniest change may have a large effect.)

In short: if you think your solution is best, build it yourself;
use it yourself; give it to your friends and neighbours.  If it catches
on, then---and only then---should you raise the `standards' standard
and march off to war.  (Well, political war anyway :-) .)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris