wsb@boise.Eng.Sun.COM (Walt Brainerd) (05/01/91)
I have been reading the recent discussion with great interest
and have a few facts/opinions to offer. It's great to see
this forum used for such discussions.
Status: Fortran 90 is an APPROVED international standard.
It is not yet published, but, in that regard, I just sent
the typeset masters to Geneve for publication. The identical
document is being processed as an Amercian standard and should
be approved as such later this year.
Name: The document adopted by ISO and to be adopted by ANSI
itself says that the language is to be called "Fortran 90",
even though the ANSI project refers to it as "Fortran Extended".
Members of X3J3: There are non-USA voting members of X3J3.
They vote on everything except when establishing a US position
on an international question (such as how the US should vote
on an ISO standard).
Recent changes: The "93 changes" someone mentioned done recently
are almost all of the order of adding a comma. Some biggies were
adding a couple of words to clarify how the INDEX function works
with arguments that are empty strings and changing a constraint
to an ordinary textual restriction (because the constraint could
not be checked at compile time as required by the standard).
There have also been some slight rearrangements and minor
corrections to the BNF. There have been no real technical
changes, other than fixing bugs, for about a year. As far as
I know, there are very few, if any, errors due to changes in the
standard in our book or "Fortran 90 Explained", but there might
be something fairly minor.
Implementations: It is silly to think that there will be no
implementations of Fortran 90 until near the beginning of the
next millenium. Any vendor who waits that long will be out
of the market.
Time to create a standard: It's an interesting question whether
there should be smaller intervals between standards with
fewer changes. Historically, the main technical content of
a proposed standard was in place around 1985. While we began
to prepare a really good document and make the information
available for public comments, those opposed to the philosophy
of the standard started arriving on X3J3 in larger numbers.
They were not successful in killing the thing, but did cripple
it and delay it. Many "compromises" were made which caused
some "standard practice" items to be added, such as namelist i/o
and include, but also allowed time to add pointers (for example).
All of this disruption meant that the time could not be spent
producing the best document possible (and if you think it is not
good to design a language by committee, it is probably worse to
have the committee as a whole try to write the document).
Vector and parallel processing: Most of what is in Fortran 90
was on a list when we began in 1977 and 1978. Obviously
parallel processing was not, but array processing was. Surely
parallel processing will be one of the main points addressed
next time (if there is one) with the help of X3H5 and others.
Standardizing existing practice: This is one of the greatest
red herrings in the development of Fortran, at least as presented
by some folks. Of course, everything in Fortran 90 is "existing
practice"! It's just a question of who has been practicing what.
Should we not adopt ideas from other languages that are common
practice (e.g., recursion)? Should we try to adopt the same
syntax as implemented by current Fortran vendors (surely "yes"
when the syntax is similar and the SEMANTICS are the same--not
really the case for either include or namelist)? Should we do
this even when a vendor has purposely chosen a different syntax
so as not to be in conflict with the proposed standard (e.g.,
DEC structures)? Strictly following the guidelines of standardizing
only what is common to current Fortran implementations, we would
have neither the character data type nor the block IF in Fortran
77 and we would not have array processing in Fortran 90. Many people
think these are among the most important features of Fortran. And
it is interesting that there is now the opinion that Fortran 90
is not going to be useful because it does not address parallel
computing. It's real tough to try to create a philosophy that
addresses these issues. Like all other arguments, this one is
raised just precisely when someone wants to argue for or against
a particular feature and they conveniently forget it in other cases.
The future: The experiences we have had trying to get out Fortran 90
indicates to me that a much different process must be used next time
(if there is one). My proposal is to have the design, implementation,
and the document done by a small group (five people?) under the
close supervision of a standards body such as X3J3 or WG5, with
both that body and the public carefully reviewing the results
at each major milestone.
--
Walt Brainerd Sun Microsystems, Inc.
walt.brainerd@eng.sun.com MS MTV 5-40
Mountain View, CA 94043
415/336-5991jlg@cochiti.lanl.gov (Jim Giles) (05/01/91)
In article <12528@exodus.Eng.Sun.COM>, wsb@boise.Eng.Sun.COM (Walt Brainerd) writes: |> [...] |> Standardizing existing practice: This is one of the greatest |> red herrings in the development of Fortran, at least as presented |> by some folks. Of course, everything in Fortran 90 is "existing |> practice"! It's just a question of who has been practicing what. |> [...] Well, I am not aware of _any_ language or _any_ implementation of any language which has "pointers" implemented in the undesireable manner that the Fortran 90 proposal defines. It is _not_ existing practice. Independent of that, it is simply not a good design. |> [...] Like all other arguments, this one is |> raised just precisely when someone wants to argue for or against |> a particular feature and they conveniently forget it in other cases. I, for one, never objected to pointers on the basis of existing practice. I would oppose the current model of pointers even if it had a long (and, presumably dark) pedigree. It is interesting that I have heard the present pointer proposal _defended_ on the basis of existing practice. I guess the argument must go something like: "it's common practice for languages to have pointers, so we'll invent something totally bizarre and _call_ it a pointer facility so we can defend it on the basis of existing practice." J. Giles
andyj@osf.org (Andy Johnson) (05/03/91)
In article <22913@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes: |> In article <12528@exodus.Eng.Sun.COM>, wsb@boise.Eng.Sun.COM (Walt Brainerd) writes: |> |> [...] |> |> Standardizing existing practice: This is one of the greatest |> |> red herrings in the development of Fortran, at least as presented |> |> by some folks. Of course, everything in Fortran 90 is "existing |> |> practice"! It's just a question of who has been practicing what. |> |> [...] |> |> Well, I am not aware of _any_ language or _any_ implementation of |> any language which has "pointers" implemented in the undesireable |> manner that the Fortran 90 proposal defines. It is _not_ existing |> practice. Independent of that, it is simply not a good design. Sure you are, it's called FORTRAN. The model that is used for POINTERs is exactly analogous to the existing pointers in most Fortran implementations: dummy arguments. If you are looking for another language which uses this pointer model, the HAL/S language (used for all of the on-board programming on the Shuttle computers) has NAME variables which are almost identical in syntax and functionality to the Fortran 90 pointers. |> [...] Like all other arguments, this one is |> |> raised just precisely when someone wants to argue for or against |> |> a particular feature and they conveniently forget it in other cases. |> |> I, for one, never objected to pointers on the basis of existing |> practice. I would oppose the current model of pointers even if it |> had a long (and, presumably dark) pedigree. It is interesting that |> I have heard the present pointer proposal _defended_ on the basis |> of existing practice. I guess the argument must go something like: |> "it's common practice for languages to have pointers, so we'll invent |> something totally bizarre and _call_ it a pointer facility so we |> can defend it on the basis of existing practice." |> |> J. Giles -- E. Andrew Johnson, OSF andyj@osf.org
jlg@cochiti.lanl.gov (Jim Giles) (05/04/91)
In article <21649@paperboy.OSF.ORG>, andyj@osf.org (Andy Johnson) writes: |> In article <22913@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes: |> [...] |> |> Well, I am not aware of _any_ language or _any_ implementation of |> |> any language which has "pointers" implemented in the undesireable |> |> manner that the Fortran 90 proposal defines. It is _not_ existing |> |> practice. Independent of that, it is simply not a good design. |> |> Sure you are, it's called FORTRAN. The model that is used for POINTERs is |> exactly analogous to the existing pointers in most Fortran implementations: |> dummy arguments. My objection to pointers is founded on the fact that they inhibit optimization and conceal errors in the presence of assignment to any of the aliased objects. Since Fortran parameter passing _prohibits_ such aliasing, your claim that they resemble pointers is false in exactly that part of the semantics I object to. The Fortran 90 proposal includes pointers to array slices, which will cause aliasing (and inhibit optimizations) on all arrays to which they are applied. This will occur even though pointers to array slices provide _no_ additional functionality! They could have been left out entirely without effecting the capabilities of the language at all. Pointers to scalars are useful in implementing recursive data structures. Although I would rather the committee support recursive data types directly, I have no strong objection to pointer being used in this way. Pointers to arrays don't do anything useful, they just inhibit optimization and generate debugging problems. J. Giles