Cheating on the types
Walt Brainerd
> This simplified fragment violates the standard by passing reals to a
> routine that expects integers.
>
> real rin, rout
> call icopy(rin, rout)
>
. . .
> subroutine icopy(iin, iout)
> integer iin, iout
>
> Seems fairly innocuous, though. Q: are there implementations
> where it would fail ?
>
Yes.
The Burroughs linkers on their old large systems B6700-B7900, etc.
used to catch this. I don't know what they do now about such
things, but I think the trend is to do more checking of this
sort along with global oprimization, so I would not recommend
doing this (or anything else nonstandard) unless you really
need to.
--
Walt Brainerd Sun Microsystems, Inc.
w...@eng.sun.com MS MTV 5-40
Mountain View, CA 94043
415/336-5991
Richard A. O'Keefe
> real rin, rout
> rin = 0.577215665 ! or whatever...
> call icopy(rin, rout)
> write(6,*) rout
> end
> subroutine icopy(iin, iout)
> integer iin, iout
> iout = iin
> return
> end
>
> Seems fairly innocuous, though. Q: are there implementations
> where it would fail?
Yes.
1. I know it's non-Standard, but there are several compilers where
the default size for integer is INTEGER*2.
2. On the B6700, integers and floats used the same representation,
but integer assignments forced the result to integer form, just
in case. The code for icopy would be something like
VALC (3,2) ; fetch value of IIN
IRND ; round to integer
NAME (3,3) ; fetch address of IOUT
STOD ; store
(I _know_ the details are wrong. Concentrate on the idea.)
This would result in the value 1.0 being stored in ROUT.
3. I don't know whether the Symbolics Fortran compiler did this,
but it _could_ have: on a tagged machine where integers and
floats have different tags, one would expect the compiler to
plant code to check that IIN has an "integer" tag.
--
Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.
Myron A. Calhoun
>In article <1991Mar20.1...@appmag.com> p...@appmag.com (Pierre Asselin) writes:
>>This simplified fragment violates the standard by passing reals to a
>>routine that expects integers.
[program deleted for brevity]
>>Seems fairly innocuous, though. Q: are there implementations
>>where it would fail ?
>Yes. It been 10 years since I've used one, but there is at least one
>Fortran implementation that uses 16 bit INTEGER's and 32 bit REAL's.
>(this in itself violates Fortran-77).
Well, DOUBLE PRECISION and INTEGER do NOT violate the standard,
and they would fail, too.
So would a similar program which asked the subroutine to copy an
array with a single assignment statement.
And for the same reason: the subroutine does not automagically know
the LENGTH of the parameters, only the address of their first part.
--Myron.
--Myron.
--
# Myron A. Calhoun, Ph.D. E.E.; Associate Professor (913) 539-4448 home
# INTERNET: m...@cis.ksu.edu (129.130.10.2) 532-6350 work
# UUCP: ...rutgers!ksuvax1!harry!mac 532-7353 fax
# AT&T Mail: attmail!ksuvax1!mac W0PBV @ K0VAY.KS.USA.NA
Walt Brainerd
>
> Yes. It been 10 years since I've used one, but there is at least one
> Fortran implementation that uses 16 bit INTEGER's and 32 bit REAL's.
> (this in itself violates Fortran-77).
>
the standard says nothing about how values are stored.
It DOES say how equivalence and common (for example)
must work, so if those things don't work correctly, the
implementation is not correct. But testing if some kind
of illegal "cheating" on types (such as using mismatched arguments
or assigning a value to a real and using an equivalenced integer)
works is not a legitimate way to determine this.
(BTW, I would say that if 16-bit integers and 32-bit reals are the
only ones available, an implementation would have a very
difficult time making equivalence and common work correctly.)
Walt Brainerd
>
> I have, using Fortran, deliberately set up subroutines which
> "cheated" on types. How else would one read multiple precision
> reals in or out? I do not consider converting them to decimal
> for output, or reading in decimal input, as reasonable; I wanted
> to be sure that the numbers were exactly the machine numbers, and
> I see no good reason to do unnecessary conversions.
>
There isn't enough info here to really understand what the problem is,
but it sounds like this is exactly what unformatted I/O is for.
> There are also cases in which I have deliberately done boolean
> operations on "real" numbers. The language designer, etc., who
> does not allow someone to deliberately cheat on the types is doing
> a great disservice to computing.
This could generate several hundred pages of comments on the
philosophy of language design and computing, but I'll try to be
briefer than that. If the "language designers" referenced above
are the people on a standards committee, then I disagree strongly.
The main purpose of a standard is to provide portability. Things
that permit cheating are not (and should not be) in a standard
because they are not portable. I did neglect to point out that,
in spite of this philosophy, there is a TRANSFER function in
Fortran 90 that converts "type" only without changing the bits,
so this allows cheating of all kinds, but perhaps the instances
will be a bit more self documenting. For example, the value of
TRANSFER (X, I)
is an integer with the same bits in it as the real X (assuming
X is real and I is integer). Also, other intrinsics that
manipulate the parts of a real number (e.g., SET_EXPONENT) should
cut down the number of cases where "cheating" is necessary.
If the "language designer" is your local friendly vendor,
then if users want nonportable features, vendors will provide
them, and use of these features, as always, tends to lock
you in to one vendor, one architecture, one compiler, ...
Sometimes they are necessary and sometimes they are convenient.
The users must judge. But putting such stuff in a standard
is definitely a DISSERVICE to computing (IMHO).
Francis Tower
I've used a compiler which did static checking of the data
descriptors and number of arguments at compile time.
ERRORs like this I like. Kept me from making some stupid
faults.
Herman Rubin
> In article <1991Mar20.1...@appmag.com>, p...@appmag.com (Pierre Asselin) writes:
> > This simplified fragment violates the standard by passing reals to a
> > routine that expects integers.
> > real rin, rout
> > call icopy(rin, rout)
> . . .
> > subroutine icopy(iin, iout)
> > integer iin, iout
> > Seems fairly innocuous, though. Q: are there implementations
> > where it would fail ?
> Yes.
> The Burroughs linkers on their old large systems B6700-B7900, etc.
> used to catch this. I don't know what they do now about such
> things, but I think the trend is to do more checking of this
> sort along with global oprimization, so I would not recommend
> doing this (or anything else nonstandard) unless you really
> need to.
I have, using Fortran, deliberately set up subroutines which
"cheated" on types. How else would one read multiple precision
reals in or out? I do not consider converting them to decimal
for output, or reading in decimal input, as reasonable; I wanted
to be sure that the numbers were exactly the machine numbers, and
I see no good reason to do unnecessary conversions.
There are also cases in which I have deliberately done boolean
operations on "real" numbers. The language designer, etc., who
does not allow someone to deliberately cheat on the types is doing
a great disservice to computing.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hru...@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
Tom Jaskiewicz
}This simplified fragment violates the standard by passing reals to a
}routine that expects integers.
}
} real rin, rout
} call icopy(rin, rout)
} write(6,*) rout
} end
}
} integer iin, iout
} return
} end
}
}Seems fairly innocuous, though. Q: are there implementations
}where it would fail ?
Yes. It been 10 years since I've used one, but there is at least one
Fortran implementation that uses 16 bit INTEGER's and 32 bit REAL's.
(this in itself violates Fortran-77).
--
##########################################################################
# The doctrine of nonresistance against arbitrary power, and oppression is
# absurd, slavish, and destructive of the good and happiness of mankind.
# -- Article 10, Part First, Constitution of New Hampshire
Pierre Asselin
routine that expects integers.
program wrong
real rin, rout
rin= 0.577215665 ! or whatever...
call icopy(rin, rout)
write(6,*) rout
end
subroutine icopy(iin, iout)
integer iin, iout
iout= iin
return
end
Seems fairly innocuous, though. Q: are there implementations
where it would fail ?
--Pierre Asselin, R&D, Applied Magnetics Corp. I speak for me.
3003...@ucsbuxa.ucsb.edu (appmag.com doesn't work yet)
Peter S. Shenkin
>I have, using Fortran, deliberately set up subroutines which
>"cheated" on types. How else would one read multiple precision
>reals in or out?....
Another application: suppose in a large program you want to write your
own routing routines to do IO, which will write to one or more files, and/or
the screen, etc., depending on the setting of various control variables. You
might want to pass a format string plus a variable or two to the routine.
But the variable's type might vary from invocation to invocation. If you can't
cheat on types, I don't think you can do this in Fortran. But if you can
declare the variable as an INTEGER, but actually pass a REAL, with an
appropriate format string, this is easily done. Admittedly, you can't pass
a DOUBLE PRECISION variable, and you still might need different routines for
passing one, two, three, etc., variables, but still life would be much more
complicated if the compiler didn't let you lie about INTEGER/REAL.
-P.
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb**************************
Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027
(212)854-1418 she...@cunixf.cc.columbia.edu(Internet) shenkin@cunixf(Bitnet)
***"In scenic New York... where the third world is only a subway ride away."***
Dave Cochran
|> routine that expects integers.
|>
|> program wrong
|> real rin, rout
|> rin= 0.577215665 ! or whatever...
|> call icopy(rin, rout)
|> write(6,*) rout
|> end
|>
|> subroutine icopy(iin, iout)
|> integer iin, iout
|> iout= iin
|> return
|> end
|>
|> Seems fairly innocuous, though. Q: are there implementations
|> where it would fail ?
|>
Oh yes. In Green Hills F77 for the Motorola 88000, it would die
with a bus error because the reals will default to real*4, with a
32 bit alignment, and the integers will default to int*2, with a
16 bit alignment. I see this all the time.
--
+------------------------------------------------------+
|Dave Cochran (coc...@spam.rtp.dg.com) |
|Data General Corporation, Research Triangle Park, NC |
+------------------------------------------------------+
|"Outside of a dog, a book is man's best friend. |
| Inside of a dog it's too dark to read." -Groucho Marx|
+------------------------------------------------------+
Herman Rubin
> > I have, using Fortran, deliberately set up subroutines which
> > "cheated" on types. How else would one read multiple precision
> > reals in or out? I do not consider converting them to decimal
> > for output, or reading in decimal input, as reasonable; I wanted
> > to be sure that the numbers were exactly the machine numbers, and
> > I see no good reason to do unnecessary conversions.
> There isn't enough info here to really understand what the problem is,
> but it sounds like this is exactly what unformatted I/O is for.
Yes and no. Try doing it from one machine to another. There are other
situations in which there are real problems.
> > There are also cases in which I have deliberately done boolean
> > operations on "real" numbers. The language designer, etc., who
> > does not allow someone to deliberately cheat on the types is doing
> > a great disservice to computing.
> This could generate several hundred pages of comments on the
> philosophy of language design and computing, but I'll try to be
> briefer than that. If the "language designers" referenced above
> are the people on a standards committee, then I disagree strongly.
> The main purpose of a standard is to provide portability. Things
> that permit cheating are not (and should not be) in a standard
> because they are not portable. I did neglect to point out that,
> in spite of this philosophy, there is a TRANSFER function in
> Fortran 90 that converts "type" only without changing the bits,
> so this allows cheating of all kinds, but perhaps the instances
> will be a bit more self documenting. For example, the value of
What good is portability if it makes doing sensible things on the
computer very difficult? This IS the situation with all of the
HLLs. Until we understand computing far more than we do now, we
cannot produce even a good language. Fortran was originally a
language for casual programming, and not intended for producing
system subroutines. Neither it, nor any other language I know, is
suited for the generation of efficient numerical procedures.
In addition, even simple operations should be programmed differently
on different machines. If vector operations are not in the language,
good code for adding two vectors and storing the result is not portable
in HLLs. If some of the vectors are short vectors in registers, I do
not know how to do a decent job on most computers using any HLL. These
are important considerations which the language designers do not seem
to be able to understand.
Al Dunbar
>routine that expects integers.
>
> program wrong
> real rin, rout
> rin= 0.577215665 ! or whatever...
> call icopy(rin, rout)
> write(6,*) rout
> end
>
> subroutine icopy(iin, iout)
> integer iin, iout
> iout= iin
> return
> end
>
>Seems fairly innocuous, though. Q: are there implementations
>where it would fail ?
>
which is hard to determine since you have written a non-
conforming program (i.e. the standard says it is wrong, but
does not dictate what it should do).
-------------------+-------------------------------------------
Al Dunbar |
Edmonton, Alberta | Disclaimer: "I disclaim disclaimers"
CANADA |
-------------------+-------------------------------------------
Stephen Chan
Does anyone have a list of error messages produced by f77 during compile-time.
Bascially, I'm after a list of error messages and their respective meanings.
Any help appreciated.
Richard A. O'Keefe
> Another application: suppose in a large program you want to write your
> own routing routines to do IO, which will write to one or more files, and/or
> the screen, etc., depending on the setting of various control variables. You
> might want to pass a format string plus a variable or two to the routine.
> But the variable's type might vary from invocation to invocation. If you can't
> cheat on types, I don't think you can do this in Fortran.
You can't do it *that* *way*. But you can do the routing!
All you have to do is write to a character variable, and pass the
already-formatted text to the routing routines. Let's face it,
type cheating or no type cheating, there is no way you can pass
an implied-DO as a subroutine parameter, so you aren't going to be
able to do a thorough job of mimicking WRITE anyway.
The 4.4BSD <stdio.h> routines and Turbo Pascal and Quintus Prolog and
Pop and many many Lisp implementations and dozens of other systems
provide a way for users to define their own streams by providing record
transfer procedure. The record transfer procedures don't need to "cheat",
because they are only ever given and only ever deliver character arrays/
strings. There is no reason why a Fortran implementation could not give
you *as an non-standard extension* a way of opening a logical unit with
record transfer going through specified user-provided routines.
Van Snyder
>... These
>are important considerations which the language designers do not seem
>to be able to understand.
>--
>Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
>Phone: (317)494-6054
>hru...@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
It's easy to sit back and throw stones. Have you sent ONE concrete proposal
to X3J3? Have you attended a meeting? Have you corresponded with ANY member
on a topic relating to the language standard? Have you asked your employer /
sponsor to foot the bill for you to join the committee?
If you don't like something about the way the language is designed, propose
an alternative, don't insult the people who worked hard to get what we have.
--
vsn...@jato.Jpl.Nasa.Gov
ames!elroy!jato!vsnyder
vsn...@jato.uucp
Jim Giles
vsn...@jato.jpl.nasa.gov (Van Snyder) writes:
|> [...]
|> It's easy to sit back and throw stones. Have you sent ONE concrete proposal
I don't know about Herman Rubin, but I have.
|> [...] Have you attended a meeting? [...]
Yes.
|> [...] Have you corresponded with ANY member
|> on a topic relating to the language standard? [...]
Yes.
|> [...] Have you asked your employer /
|> sponsor to foot the bill for you to join the committee?
No. Our representative on the committee sits just down the hall from
me. Although we have differences, I was satisfied that he generally
represented my interests with regard to Fortran. Even if I did not,
no organization is allowed more than one full member on the committee.
|> [...]
|> If you don't like something about the way the language is designed, propose
|> an alternative, don't insult the people who worked hard to get what we have.
|>
|> --
|> vsn...@jato.Jpl.Nasa.Gov
|> ames!elroy!jato!vsnyder
|> vsn...@jato.uucp
I have the third public review letters here in front of me. The letter
from W. Van Snyder of the Nasa Jet Propulsion Laboratory was among the
most critical of them. While I don't agree with all that he said
(or left unsaid), I think the following quote reflects my own experience
with the committee better than anything I could have said myself:
"But, some comments appear not to have been considered, some appear
to have been considered only in part, and the responses to some
suggest that the examining subcommittee either didn't understand
what I advocated, or chose not to (I think that's called _stonewalling_).
Or, perhaps a shorter comment later on says the same thing more
succinctly:
"Please keep to the point of our proposals, instead of setting up
easily-kicked-down straw men."
I didn't send in a letter on the third public review since I was
certain that it would be ignored or misinterpreted like my first
two public review comments were. On the second public review, for
example, I carefully listed several reasons that I opposed the
introduction of POINTERs in the proposal. One of the responses
I got back was:
"You are correct that allocatable arrays are not needed because the
pointer facility provides equivalent functionality. [...] "
This, of course, was total garbage. I recommended _keeping_ the
allocatable arrays and _dropping_ pointers - not the other way
around! No native English speaker could possibly have interpreted
my comments as a recommendation to drop allocatable arrays as
redundant.
So, before reprimanding people for complaining about the proposed
standard, remember that our experience with the committee may have
been as unacceptable as yours (or more so). Complaining in a public
forum is the only option left to those of us whose comments were
ignored or misrepresented by the committee in the past.
J. Giles
Dave Cochran
|>
|> Does anyone have a list of error messages produced by f77 during compile-time.
|> Bascially, I'm after a list of error messages and their respective meanings.
|>
For which FORTRAN? I can give you lists from about 4 different ones, and each
list would be unique. There are a few errors that are pretty generic, but many,
many others that can be found only in particular products.
Herman Rubin
> >... These
> >are important considerations which the language designers do not seem
> >to be able to understand.
> to X3J3? Have you attended a meeting? Have you corresponded with ANY member
> on a topic relating to the language standard? Have you asked your employer /
> sponsor to foot the bill for you to join the committee?
>
> If you don't like something about the way the language is designed, propose
> an alternative, don't insult the people who worked hard to get what we have.
Have you read my postings to comp.lang.misc and comp.arch? The "gurus"
reading the postings of others, as well as mine, take the attitude
We know what is best, and we know what is basic, and we will
provide all the tools which are good for you.
There is one situation in which I did send in detailed suggestions to a
meeting--this one was on the IEEE standards for floating point hardware,
which I find decidedly poor. I sent in a 5 page list, and I stated that
I had seen the request for such in an announcement of an open meeting.
So what did I receive in response? An invitation to attend that same
meeting!
These committes make it very expensive to participate. The cost of
even obtaining copies of proposals are quite high for the expense budget
of a university department. These committees are not really soliciting
suggestions from users, and they seem to be resisting it.
Also, most of my suggestions go in the opposite direction even from the
idea of a language standard. The point is that what we need is great
flexibility, not restriction. If these committees want to know what
users might want, let them announce the situations where users can see
them. Requests for suggestions should appear in the journals of the AAAS,
American Mathematical Society, American Statistical Association, etc.
Summaries of suggestions made should also appear in those journals.
Does it make sense for me to attend a meeting of such a committee instead
of teaching and doing research? I do attend meetings, but I probably would
have not much interest and little to contribute to most of it. The people
with complaints and suggestions can make them quite plainly without spending
lots of time at meetings.
The real problem is that these standards committees feel that restrictive
standards are needed, instead of great flexibility, and that efficiency may
involve doing what is not even thought of at the time.
C.E. Thompson
>In article <1991Mar20.1...@appmag.com> p...@appmag.com (Pierre Asselin) writes:
>}This simplified fragment violates the standard by passing reals to a
>}routine that expects integers.
>}
>} program wrong
>} real rin, rout
>} rin= 0.577215665 ! or whatever...
>} call icopy(rin, rout)
>} write(6,*) rout
>} end
>}
>} subroutine icopy(iin, iout)
>} integer iin, iout
>} iout= iin
>} return
>} end
>}
>}Seems fairly innocuous, though. Q: are there implementations
>}where it would fail ?
>
>Yes. It been 10 years since I've used one, but there is at least one
>Fortran implementation that uses 16 bit INTEGER's and 32 bit REAL's.
>(this in itself violates Fortran-77).
>
From the mists of time: on TITAN (and other Atlas-1 and Atlas-2 Fortran
implementations as well, I expect) integers were halfwords (24 bits) while
reals were words (48 bits). The above code would not have worked.
This implementation long preceded the Fortran 77 rules on storage units.
However, in some cases it was compatible with them: for example, an INTEGER
array and a REAL array with the same number of elements that were
EQUIVALENCEd or overlaid in COMMON would correspond 1:1 (half the space
in the INTEGER array was "wasted"). Copying the INTEGER array element by
element to another such INTEGER/REAL pair would not have the effect of
copying the REAL array (only half the bits would be moved), and there is
nothing in the Fortran 77 standard to say that it should.
Chris Thompson
JANET: ce...@uk.ac.cam.phx
Internet: cet1%phx.ca...@nsfnet-relay.ac.uk
Van Snyder
>|> If you don't like something about the way the language is designed, propose
>|> an alternative, don't insult the people who worked hard to get what we have.
In article <18...@lanl.gov> j...@cochiti.lanl.gov (Jim Giles) writes:
>I have the third public review letters here in front of me. The letter
>from W. Van Snyder of the Nasa Jet Propulsion Laboratory was among the
>
>So, before reprimanding people for complaining about the proposed
>standard, remember that our experience with the committee may have
I didn't complain about complaining about the proposed standard. I complained
about asserting that the members of the standards committee were unable to
understand general principles of language design.
>been as unacceptable as yours (or more so). Complaining in a public
>forum is the only option left to those of us whose comments were
^^^^^
I didn't publish my criticisms -- X3J3 did.
>ignored or misrepresented by the committee in the past.
>
>J. Giles
I've been critical of the standard, and critical of the treatment my comments
received, but I've tried to stay away from character assasination. But I
understand that in some environments, the tradition is first to try to
demonstrate that somebody with whom you disagree can't possibly possess the
mental and moral capacity to be right, or even sincere, and only then to
disagree with what he said.
--
vsn...@jato.Jpl.Nasa.Gov
ames!elroy!jato!vsnyder
vsn...@jato.uucp
Van Snyder
>In article <1991Mar22.2...@jato.jpl.nasa.gov>, vsn...@jato.jpl.nasa.gov (Van Snyder) writes:
>> In article <85...@mentor.cc.purdue.edu> hru...@pop.stat.purdue.edu (Herman Rubin) writes:
>> >... These
>> >are important considerations which the language designers do not seem
>> >to be able to understand.
>
>> It's easy to sit back and throw stones. Have you sent ONE concrete proposal
>> to X3J3? Have you attended a meeting? Have you corresponded with ANY member
>> on a topic relating to the language standard? Have you asked your employer /
>> sponsor to foot the bill for you to join the committee?
>>
>> If you don't like something about the way the language is designed, propose
>> an alternative, don't insult the people who worked hard to get what we have.
>The real problem is that these standards committees feel that restrictive
>standards are needed, instead of great flexibility, and that efficiency may
>involve doing what is not even thought of at the time.
I agree with that. I just don't like character assasination. Complain
about what they're doing, or how they're doing it, not about their mental
and moral abilities.
>--
>Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
>Phone: (317)494-6054
>hru...@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
--
vsn...@jato.Jpl.Nasa.Gov
ames!elroy!jato!vsnyder
vsn...@jato.uucp
Jim Giles
I'd like to complain about people who hold things up by complaining
about people complaining - something should be done about it.
Monty Python
(Followed by a 16-ton weight being dropped on the man's head.)
|> [...] I complained
|> about asserting that the members of the standards committee were unable to
|> understand general principles of language design.
I didn't make such an assertion. And neither did Herman Rubin (who
was legitimately pointing out considerations that standards committees
_do_ tend to consistently overlook).
However, now that you've brought it up: I'd _not_ claim that individual
members of the committee were unable to understand general principles of
language design, I _would_ claim that the committee as a whole is unable
to practice such principles. Indeed, aside from ALGOL 60, I can't think
of a single successful language which was committee designed (and ALGOL
was _mostly_ done by a small subset of the committee).
Why should this be so? Consider the answers to the first public
review. Most consisted of "the committee considered your objection
but decided to do X anyway." One of the committee members explained
such non-answers (in this very newsgroup) as being the result of the
fact that it was not possible to get a majority of the committee to
agree to a technical rationale for individual features. It is my
opinion that if there is not a single, easily described technical
reason for a new feature, it should not be included at all! It
appears that much of the new proposed standard consists of politically
"convenient" compromises. That is: "you vote for my pet feature and
I'll vote for yours." This is _not_ the way to design a language - or
even new features for one. Committees should stick to what they do
fairly well: standardizing common practice.
|> [...]
|> >been as unacceptable as yours (or more so). Complaining in a public
|> >forum is the only option left to those of us whose comments were
|> ^^^^^
|> I didn't publish my criticisms -- X3J3 did.
Unfortunately, they didn't. They just sent them around to committee
members and alternates. It is my opinion that they _should_ be
published as widely as possible in order that the user community
get the benefit of the thinking of other users. The responses should
also be published (all of them) so the user community can see how the
committee has dealt with each issue.
|> [...] But I
|> understand that in some environments, the tradition is first to try to
|> demonstrate that somebody with whom you disagree can't possibly possess the
|> mental and moral capacity to be right, or even sincere, and only then to
|> disagree with what he said.
There is another school of thought which expects honesty and
competence from others until such time as it is clearly demonstrated
not to exist. The committee's responses to the public reviews as well
as other actions are a matter of public record. I have bent over
backward in the assumption that their conduct is a result of political
deadlock, lack of time and low budget within the committee as a whole
and not a result of incompetence or dishonesty of individual members.
But, the fact remains, the net effect is unsatisfactory and deserving
of criticism. It is all the more important that such discussion be
public since the vast majority of Fortran users are unaware of the
issues or have only heard the pro-Fortran 90 story from the available
books on the subject.
J. Giles
The Black Sheep
obsolescent? Really, i just can't handle doing programs while tripping over
small details and phantom errors from nowhere and tricky compilations and
core dump after core dump after execution...
Please, answer me, enlighten me on my feelings toward f77...
... cuz i still think it s*cks!! :-p
*******************************************************************************
"Mother, do you think they'll like this song?"
_____ _ /
Ron A. Echeverri | | \ /
BSAE 1994 Univ. of So. California |he |-<lack \heep
email: eche...@sal8.usc.edu | |_/ /
/
Keith Bierman fpgroup
Excuse me, but is it just me, or is fortran a language so old it is becoming
obsolescent? Really, i just can't handle doing programs while tripping over
small details and phantom errors from nowhere and tricky compilations and
core dump after core dump after execution...
Have you used modern tools (static analysis tools for FORTRAN are at
least 15 years old ... older I'm sure).
Tried debugging C++ codes without good support tools ? I don't think
the language is at fault. But feel free to stop coding in it. It is a
free country.
--
----------------------------------------------------------------
Keith H. Bierman kbie...@Eng.Sun.COM | k...@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043
Myron A. Calhoun
>Excuse me, but is it just me, or is fortran a language so old it is becoming
>obsolescent? Really, i just can't handle doing programs while tripping over
>small details and phantom errors from nowhere and tricky compilations and
>core dump after core dump after execution...
> Please, answer me, enlighten me on my feelings toward f77...
OH! I thought you were talking about our Modula-2 compiler!
Jim Giles
> Excuse me, but is it just me, or is fortran a language so old it is becoming
> obsolescent? Really, i just can't handle doing programs while tripping over
> small details and phantom errors from nowhere and tricky compilations and
> core dump after core dump after execution...
Everything you say here can be applied to most languages of widespread
popular use. And new languages aren't much better - the funny little
bugs and details you talk about are not yet shook out of new designs.
However, Fortran is one of the most stable and well understood languages
around. There are fewer such minutiae to trip over in Fortran than any
other language still in widespread use. Certainly you don't think C or
Pascal are better with respect to traps and pitfalls? Or maybe you're
just using UNIX all the time and have never seen a good implementation
of anything but C? (Frankly, I've never even seen a good C implementation
on plain vanilla UNIX - the good ones are all expensive commercial
products.)
J. Giles
P.S. Unfortunately, everything I just said about Fortran being stable
is about to be eradicated by the ANSI committee. Oh well.
Tom B. O'Toole
The rest of us who are interested in the subject don't give a
shit that you think it sucks. Comments like yours, the only
purpose of which is to annoy, don't add anything to the subject
dealt with here.
--
Tom O'Toole - ecf_...@jhuvms.bitnet - JHUVMS system programmer
Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218
ease!Trim!eeeaaaassse!trimtrimtrimeeeeeeaaaaassetrimease!trim!ease!trimeaase
Irving Chidsey
<
<J. Giles
<
<P.S. Unfortunately, everything I just said about Fortran being stable
<is about to be eradicated by the ANSI committee. Oh well.
Not realy, the real movers and shakers will by those instructed to
implement the ANSI committees ideas first so that they can have the first
real Fortran90 on the street. And we'll all be beta testers!
Irv
--
I do not have signature authority. I am not authorized to sign anything.
I am not authorized to commit the BRL, the DA, the DOD, or the US Government
to anything, not even by implication. They do not tell me what their policy
is. They may not have one. Irving L. Chidsey <chi...@brl.mil>
Brian Kauffman
>Excuse me, but is it just me, or is fortran a language so old it is becoming
>obsolescent? Really, i just can't handle doing programs while tripping over
>small details and phantom errors from nowhere and tricky compilations and
>core dump after core dump after execution...
>
> Please, answer me, enlighten me on my feelings toward f77...
>
> ... cuz i still think it s*cks!! :-p
>
I hope this is enlightening:
I use Fortran every day and the problems you mention are not problems for me.
I've also used C extensively, but for my needs, it wouldn't be worth the
effort to convert my models from Fortran to C. It seems to be a recurring
theme that someone proclaims that Fortran sucks and we should all switch to
C (or whatever). The bottom line is, for lots of folks, switching is not
worth the effort, and quite possibly not even an improvement.
-Brian
Tom Kovar
}This simplified fragment violates the standard by passing reals to a
}routine that expects integers.
}
} program wrong
} real rin, rout
} rin= 0.577215665 ! or whatever...
} call icopy(rin, rout)
} write(6,*) rout
} end
}
} subroutine icopy(iin, iout)
} integer iin, iout
} iout= iin
} return
} end
}
}Seems fairly innocuous, though. Q: are there implementations
}where it would fail ?
>
>implementations as well, I expect) integers were halfwords (24 bits) while
>reals were words (48 bits). The above code would not have worked.
>
>This implementation long preceded the Fortran 77 rules on storage units.
>However, in some cases it was compatible with them: for example, an INTEGER
>array and a REAL array with the same number of elements that were
>EQUIVALENCEd or overlaid in COMMON would correspond 1:1 (half the space
>in the INTEGER array was "wasted"). Copying the INTEGER array element by
>element to another such INTEGER/REAL pair would not have the effect of
>copying the REAL array (only half the bits would be moved), and there is
>nothing in the Fortran 77 standard to say that it should.
Another wonderfull thing - on old Telefunken TR440 (or something like that)
using a 48 bit word, I think 2 bits were passed within the word,
identifying the kind of the argument... So you would have been caught... :-)
Tom Kovar
Kurt Hirchert
>routine that expects integers.
>
> program wrong
> real rin, rout
> rin= 0.577215665 ! or whatever...
> call icopy(rin, rout)
> write(6,*) rout
> end
>
> subroutine icopy(iin, iout)
> integer iin, iout
> iout= iin
> return
> end
>
>Seems fairly innocuous, though. Q: are there implementations
>where it would fail ?
One of the early FORTRAN implementations for the IBM 360 line used decimal
arithmetic rather than binary arithmetic for integer variables and
computation. In that implementation, the above program would have died
with a machine interrupt because the "integer" iout would have contained
bit patterns that were not valid decimal digits.
As a general rule, it is dangerous to use techniques based on the effects
of the implementation of a language's features rather on the features
themselves. No matter how logical it may seem to implement those features
in that particular way, somewhere out there you will find a machine in
which the implementation does not have the property you exploited.
(an obvious corollary to Murphy's law)
--
Kurt W. Hirchert hirc...@ncsa.uiuc.edu
National Center for Supercomputing Applications
Dave Cochran
|> Excuse me, but is it just me, or is fortran a language so old it is becoming
|> obsolescent? Really, i just can't handle doing programs while tripping over
|> small details and phantom errors from nowhere and tricky compilations and
|> core dump after core dump after execution...
|>
|> Please, answer me, enlighten me on my feelings toward f77...
|>
|> ... cuz i still think it s*cks!! :-p
|>
Wishful thinking, huh? :-)
Well, find a language that doesn't have "small details" for the uninitiated
to trip over, and at the same time produces code that'll add 1 and 1 together in
less than a week, and the entire computer industry will be revolutionized.
Really, it all depends on what you want to do when you grow up. If you want to
go to work for a computer manufacturer, then forget the FORTRAN and concentrate
on C. If you want to go to work in any other scientific field on earth, then
you better tough it out. It's old, but because of that there are millions of
lines of code extant and tens of thousands of compilers installed at user sites,
so you'll probably end up using one.
I took calculus, which is a lot older than FORTRAN, and I thought THAT sucked,
but that doesn't mean that it's obsolete.
Van Snyder
>In article <45...@alliant.Alliant.COM> t...@Alliant.COM (Tom Jaskiewicz) writes:
>>In article <1991Mar20.1...@appmag.com> p...@appmag.com (Pierre Asselin) writes:
>>}This simplified fragment violates the standard by passing reals to a
>>}routine that expects integers.
>>}
>>} program wrong
>>} real rin, rout
>>} rin= 0.577215665 ! or whatever...
>>} call icopy(rin, rout)
>>} write(6,*) rout
>>} end
>>}
>>} subroutine icopy(iin, iout)
>>} integer iin, iout
>>} iout= iin
>>} return
>>} end
>>}
>>}Seems fairly innocuous, though. Q: are there implementations
>>}where it would fail ?
>>
>>Yes. It been 10 years since I've used one, but there is at least one
>>Fortran implementation that uses 16 bit INTEGER's and 32 bit REAL's.
>>(this in itself violates Fortran-77).
>>
>
>From the mists of time: on TITAN (and other Atlas-1 and Atlas-2 Fortran
>implementations as well, I expect) integers were halfwords (24 bits) while
> deleted]
Also from the mists of time: I think on CDC 6600/7600, an integer was
represented using only the fraction of a floating point number, with the
exponent zero. If a number with zero exponent was acted upon by a floating
point instruction, or a number with non-zero exponent was acted upon by an
integer instruction, interrupts happened. But I may have this wrong.
--
vsn...@jato.Jpl.Nasa.Gov
ames!elroy!jato!vsnyder
vsn...@jato.uucp
Van Snyder
Sounds like he doesn't like C much either.
The problems with Fortran are well known. So why doesn't it disappear?
Because Pascal, Algol, C, ... don't know how to compute, for one reason or
another. E.g., no open arrays in pascal, all intermediates coerced to double
in (pre-ANSI) C, no 2 argument arctangent in Modula-2, no standardized I/O
anywhere except Fortran, serious portability problems for the arcane languages,
no decent compilers for (insert your favorite) ...
--
vsn...@jato.Jpl.Nasa.Gov
ames!elroy!jato!vsnyder
vsn...@jato.uucp
Jim Giles
|> [...] Anyone who
|> tells biologists that they should learn to program in FORTRAN really doesn't
|> like biologists.
And, anyone who tells them to learn C must actively _hate_ them.
J. Giles
Michael J. Corrigan
>obsolescent? Really, i just can't handle doing programs while tripping over
>small details and phantom errors from nowhere and tricky compilations and
>core dump after core dump after execution...
>
> Please, answer me, enlighten me on my feelings toward f77...
>
> ... cuz i still think it s*cks!! :-p
fortran is not becoming obsolescent. It is a LOT better than it used to
be ( do while e.g.)
It may be you. Humans are not as willing/able to perform rote memorization,
learning of complex tasks nor to concentrate for long periods as they get older
in my experience. Time to let the youngsters in.
If you had learned fortran on a non-unix system and are a dedicated unix
weenie then you would be thankful that there is a fortran compiler.
f77, although beefed up in recent years on some systems ( they tend to
give it a new name at that point, though) is still implemented
poorly on any number of UNIX systems. Possibly you have one of those.
For example, on some systems there is no symbolic debugger support
for f77. The syntax checker possibly isn't informative. Intermodule
cross-referencing at source level would be nice. That's not fortran's
fault but the vendor.
On tripping over small details. I don't know any computer language
/compiler where characters can be left out of a program and you will still get
the same result. The program has to be letter-perfect in any language. Every
t crossed an i dotted, so to speak.
As for phantom errors, presumably those would be run-time errors.
Usually this is due to trashed memory. Check your array bounds. Check
passed data types for consistency between caller and callee.
Tricky compilations ??? Try "man make"
If you do "mkdir core" then you won't get any more core dumps.
Michael J. Corrigan
Pete Roth
>
[ deleted ]
>Also from the mists of time: I think on CDC 6600/7600, an integer was
>represented using only the fraction of a floating point number, with the
>exponent zero. If a number with zero exponent was acted upon by a floating
>point instruction, or a number with non-zero exponent was acted upon by an
>integer instruction, interrupts happened. But I may have this wrong.
>
BUT: we Fortraners are forever moving ancient code from machine to machine.
When do YOU give up on code and rewrite from scratch?
- - - - - - - - - - - - - - - - - - - - - - - - - -
Peter N Roth ro...@dtoa1.dt.navy.mil
Objects in this office are closer than they appear.
Van Snyder
>
> Excuse me, but is it just me, or is fortran a language so old it is becoming
> obsolescent? Really, i just can't handle doing programs while tripping over
> small details and phantom errors from nowhere and tricky compilations and
> core dump after core dump after execution...
and lots of folks have since responded with various apologies for Fortran.
Isn't it interesting that the "experts" have been criticizing Fortran since
1956, and it STILL hasn't gone away? The problem is, the "experts" who
design alternatives don't know what's needed for _Computing_. Sure,
Fortran doesn't have records or recursion. But Pascal and Modula-2 don't
have open arrays or generic intrinsic functions. And C, until recently
standardized by ANSI, coerced all intermediate floating point expressions
to double precision; C still lacks generic intrinsic functions. With Fortran
90 having records and recursion, AND array processing, the "modern" languages
touted as alternatives by the "experts" seem to be falling further behind.
I've criticized Fortran 90 because it's not all it should be, but I don't
see any REAL alternatives for _Computing_.
It's interesting that Guy L. Steele, Jr., the main designer of Scheme (an
especially clean Lisp-like language), and the editor of "Common Lisp, the
Language", editions 1 and 2, is presenting a paper "Compiling Fortran at
10 Gigaflops" at the upcoming SIGPLAN conference on Programming Language
Design and Implementation.
--
vsn...@jato.Jpl.Nasa.Gov
ames!elroy!jato!vsnyder
vsn...@jato.uucp
Myron A. Calhoun
> Excuse me, but is it just me, or is fortran a language so old it is becoming
> obsolescent? Really, i just can't handle doing programs while tripping over
> small details and phantom errors from nowhere and tricky compilations and
> core dump after core dump after execution...
One of my colleagues who doesn't read this group had this to say about
this thread:
>I wonder whether the language addicts can step away far enough from
>their addictions to see what they are hollering about.
>The fortran addicts are hooked on fortran because it gives them
>the freedom (and the responsibility) to do 'risky' things, i.e.
>the freedom do do (almost) anything the machine can be made to do.
>They may have to pay the price by reading crash dumps in hex ...
>The 'structured-language' addicts are addicted (not to misnamed
>'structured languages' but) to structured code, because they can build
>or buy compilers that can proofread much of that code for adherence
>to a safety dogma (thou shalt not do arithmetic on address variables;
>thou shalt not compare characters to cardinals ...). Those addicts
>have forfeited their claims to freedom in exchange for the promised
>land of make-believe correctness ....
>Just as adherence to style guides guarantees uniformly mediocre
>(mass-produced?) 'correct prose' so use of 'structured languages'
>guarantees 'stodgy but reliable code'. Neither style guides nor
>structured languages leave room for genius. Because genius is scarce
>and style guides and structured languages are popular, both claim to let
>people join the select class of genius without paying the entry fee.
Don MacQueen
|>
|> > Excuse me, but is it just me, or is fortran a language so old it is becoming
|> > obsolescent? Really, i just can't handle doing programs while tripping over
|> > small details and phantom errors from nowhere and tricky compilations and
|> > core dump after core dump after execution...
The best response would have been silence.
--
--------------------
Don MacQueen
ma...@miguel.llnl.gov
--------------------