Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)

[hen@bu-cs.UUCP (Bill Henneman)]

Um, I think I made a careless error.  I have been responding to messages
in net.ai without checking the cross-listings of the postings.  I
phrased my reply under the misapprehension that I was conversing with an
experienced LISP user.  My curt reply was based on a wrong model of how
elliptic I could be.  The only thing I accused you of was basing an
argument on experience you didn't have.  I'll start over.

If you say that PASCAL or ADA ought to be able to link FORTRAN library
routines, I'll interpret the statement as a comment about the benefits
gained from using carefully crafted library packages like the IMSL
routines vs. the cost of accommodating the linkage.  Any compiler builder
will agree - something like the support required has to be there, the
cost of accommodation is small, the benefit is great.  It ought to be
done.  

But LISP is not some sort of Cambridge Polish form of FORTRAN.  It makes
different assumptions about the computing environment.  LISP is
interpreted, and has a rather devil-may-care attitude about errors,
since it can inspect the entire run time environment to take corrective
action.  The FORTRAN compiler inserts certain implicit assumptions about
the run-time environment into compiled code, and refuses to compile
"dangerous-looking" code, because it can't see the run-time environment.

While most LISPs I am familiar with can load FORTRAN library routines,
none fully support them.  As a simple example of the difference between
allowing alien routines to be called and supporting their use, consider
the trivial problem of linking to SQRT from LISP.  This does involve a
trivial reformatting of numbers to support the call. No problem - float
the number if necessary, build the calling sequence and call SQRT.  But
what happens if SQRT detects what it thinks is an error condition (such
as a negative number being passed)?  Who gets to handle the problem?
SQRT assumes the presence of a fairly elaborate run-time support module
to handle error messages, and in this case to provide standard fix-ups.
Does the LISP user get a FORTRAN error message with the answer
canonically set to 0, or a LISP error break?  The only answer
acceptable to the LISP user is to be thrown into the LISP error break,
so the FORTRAN error handler has to be trapped by a special LISP module
to support the FORTRAN run-time routine.

Building such a beast is a non-trivial job, since you have to take into
account all the different ways FORTRAN routines might react to error
conditions.  Some FORTRAN library routines depend on interrupt handlers
being present, or specific interrupts being masked off.  Some FORTRAN
graphics library routines feel free to use the complete I/O capabilities
of the machine.  In fact, in order to provide LISP functions with the
ability to use the FORTRAN routines called, LISP ends up having to
simulate (and override) the full run-time environment of FORTRAN.  This
simulation is a complete add-on, since LISP treats all such
environmental issues in a completely different fashion.

And so, we come to my assertion that you might as well try to link
SNOBOL routines.  Well, if you have provided the full run-time support
for FORTRAN library routines, you get SNOBOL support essentially for
free!  Read "The Macro Implementation of SNOBOL 4" by Ralph E. Griswold
to see how much SNOBOL relies on the FORTRAN environment. 

In order to get the benefit, you have to pay the cost.  The cost in the
case of PASCAL supporting FORTRAN library routines is paid in how you
code a module which in some form or another had to be there anyway, and
the user sees nothing but benefits.  The cost in the case of LISP
supporting FORTRAN library routines is paid in designing a module which
allows things to be done in a way inconsistent with the way everything
else is done in LISP, leading to code which is difficult to maintain, an
interface which is impossible to document, and a very angry user
community.  It just isn't worth it.