From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site bu-cs.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!bu-cs!hen From: hen@bu-cs.UUCP (Bill Henneman) Newsgroups: net.ai,net.lang.lisp,net.lang.ada Subject: Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details) Message-ID: <272@bu-cs.UUCP> Date: Tue, 19-Mar-85 11:15:13 EST Article-I.D.: bu-cs.272 Posted: Tue Mar 19 11:15:13 1985 Date-Received: Thu, 21-Mar-85 02:30:54 EST References: <253@bu-cs.UUCP>, <320@cmu-cs-k.ARPA> Organization: Boston Univ Comp. Sci. Xref: watmath net.ai:2645 net.lang.lisp:405 net.lang.ada:244 List-Id: 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.