NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/fortran/4776

Internet Message Format | 1992-12-16 | 4.3 KB

Path: sparky!uunet!stanford.edu!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!burley
From: [e-mail] (Craig Burley)
Newsgroups: comp.lang.fortran
Subject: Re: SUMMARY: CHARACTER FUNCTION as dummy argument
Date: 16 Dec 92 14:23:44
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
Lines: 68
Message-ID: <[e-mail]>
References: <[e-mail]>
    <[e-mail]>
NNTP-Posting-Host: apple-gunkies.gnu.ai.mit.edu
In-reply-to: [e-mail]'s message of Tue, 15 Dec 1992 19:17:17 GMT

In article <[e-mail]> [e-mail] writes:

       I won't comment on whether or not the VAX way of passing character
   arguments (functions and/or variables) is efficient or not since someone
   like Steve Lionel is in a _much_ better position to answer (although I
   do suspect there's no performance hit on VMS because ALL character
   entities are passed by [the address of a] descriptor).  However, while I do
   appreciate issues of efficiency in Fortran code, CHARACTER manipulations
   are one place I think we should "look the other way", so to speak.  These
   manipulation most often occur in the user interface, and users are SLOW
   DEVICES ;-)  Furthermore, if you DO need efficient character manipulation,
   try recoding using the equivalent of Hollerith data: it's MUCH faster to
   compare INTEGER variables, even in a loop, than to compare CHARACTER
   variables.  (Well, I admit there is likely hardware dependency in this...).

Oh, I'm sure on the VAX it makes no difference.  I don't take issue
with the assertion that we should "look the other way" when it comes to
_implementation_ of CHARACTER -- heck, I've done three such implementations
in my lifetime (an early one adding PL/1-like character support to a system
software package written, essentially, in FORTRAN 66), and they've all
been implemented at least initially in a "slow" way.  (I got to optimize
the first one later, and it made a _visible_ difference at 9600 baud!)

My complaint is that language _extensions_ should not be added in a way
that is likely to slow down, even a little bit, programs that don't use
them, even on different machines.  That's what the VAX extension under
discussion does.  Just as the VAX extension that makes CALL FOO different
from CALL FOO() introduces nonportability to some software written on
the VAX that could otherwise be portable to different architectures.

I admit that, in this case, the performance hit is small (perhaps
immeasurable in most programs) and, if the feature is truly _needed_
(which seems unlikely), there's no obvious alternative, so perhaps it's
worth having been done to some people.  _But_, I can't do it in GNU
Fortran, nor can it be done in f2c, or many other machines, because of
the requirements it places on calling sequences -- a _better_ (nonobvious)
alternative (which I won't bother suggesting, as it's too late now) wouldn't
have had _any_ of these problems.

Language design is to compiler implementation as diamond-cutting
is to pottery.  No matter how good you are at pottery, you do not
necessarily have the skills for cutting a diamond, and if you are going
to try to do so even a little bit, start on a diamond that nobody
cares about (i.e. with very little value).

(I don't claim I'm any good at language design myself, btw, though I've
proven some skill at it in the past.  But I know bad language design about
as well as a potter might know a bad diamond cut.  Anyone can be a critic. :-)

BTW, the jury apparently is still out on whether

    CHARACTER*(*) CFUNC
    EXTERNAL CFUNC
    CALL FOO(CFUNC)
    END

is standard-conforming.  VAX/VMS FORTRAN doesn't support it, neither does
GNU Fortran (for the moment; it's much easier for me to fix g77 than for
DEC to fix its compiler, since I have to worry only about the front-end
support, while DEC has to be concerned with how their extension would
interact with this possibly-standard feature), but perhaps some compilers
do.  If I don't get a definitive answer referencing the standard
within a day or so, I'll try and get other standards people involved in
coming up with one.
--

James Craig Burley, Software Craftsperson    [e-mail]
Member of the League for Programming Freedom (LPF) [e-mail]