Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!cornell!uw-beaver!microsoft!bobal
From: bobal@microsoft.UUCP (Bob Allison)
Newsgroups: comp.lang.fortran
Subject: Re: An exercise in futility
Keywords: Yale, Schlage, MasterLock, tumbler
Message-ID: <233@microsoft.UUCP>
Date: 10 Jan 89 15:35:40 GMT
References: <586@mbph.UUCP>
Reply-To: bobal@microsoft.UUCP (Bob Allison (uunet!microsoft!bobal))
Organization: Microsoft Corp., Redmond WA
Lines: 43

In article <586@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM) writes:
>
> [...]
>
>Most fortran programmers probably never hear of the American
>National Standards Institute, inc. or ANSI X3.9-1978; they
>learn to use fortran from their vendor's Language Reference
>Manual.  They work under the delusion that they are using
>a "STANDARD" language thinking that they are producing "PORTABLE"
>code so long as it compiles without errors.  Little do they know
>that it is an exercise in futility.
>
>----------------------------------------------------------------------
>Albert Hybl, PhD.              Office UUCP: uunet!mimsy!mbph!hybl

Don't be ridiculous.  Both IBM and DEC, and a whole bunch of other
vendors print their manuals in two colors, distinguishing standard
features from vendor extensions.  I can just see this guy reading one
of these manuals saying "Gosh, I wonder if they ran out of black ink?".
(BTW, I think this is an excellent feature, and users should demand
it of each vendor, for C too now).

I can just see this same guy using DEC SYS$ calls, or vectorizer commands
on his CRAY/CDC and figuring that this stuff will work when he ports it
to his PC.

Portability is a very difficult problem, and I believe it is demonstrable
that even the most strictly standard-conforming program is not portable
(File name syntax is a traditional problem).  But let's not trivialize the
very real problems of portability by assuming people are idiots.  At that
point, no solution is possible (or even desirable).  Even relative portability 
requires very hard work and very intelligent programming.

I thought that a previous note which indicated a possible reason why there 
is no standard behavior for SQRT(-16.) was very good (e.g., IEEE lets 
you specify whether you want an exception or a NaN).  Starting from there, 
how can we develop a solution which is amenable to different floating point 
methods which still attempts to provide portability?  Is such a feature 
worth the cost?  Let's try to avoid polemics and attempt to formulate 
some solutions instead of cursing the night.

Bob Allison
("Who turned off the %$&# lights!?")