Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.fortran
Subject: Re: Cheating on the types
Summary: The purpose of a language
Message-ID: <8517@mentor.cc.purdue.edu>
Date: 22 Mar 91 15:16:08 GMT
References: <1991Mar20.195732.15376@appmag.com> <10146@exodus.Eng.Sun.COM> <10208@exodus.Eng.Sun.COM>
Sender: news@mentor.cc.purdue.edu
Lines: 52

In article <10208@exodus.Eng.Sun.COM>, wsb@boise.Eng.Sun.COM (Walt Brainerd) writes:
> In article <8421@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
 
> > 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.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)