Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!sun-barr!newstop!exodus!boise.Eng.Sun.COM!wsb
From: wsb@boise.Eng.Sun.COM (Walt Brainerd)
Newsgroups: comp.lang.fortran
Subject: Re: Cheating on the types
Message-ID: <10208@exodus.Eng.Sun.COM>
Date: 21 Mar 91 17:02:06 GMT
References: <1991Mar20.195732.15376@appmag.com> <10146@exodus.Eng.Sun.COM> <8421@mentor.cc.purdue.edu>
Sender: news@exodus.Eng.Sun.COM
Lines: 48

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.

> 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).
--
Walt Brainerd        Sun Microsystems, Inc.
wsb@eng.sun.com      MS MTV 5-40
                     Mountain View, CA 94043
                     415/336-5991