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.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!encore!mist
From: pierson@mist (Dan Pierson)
Newsgroups: comp.lang.ada
Subject: Re: Ada vs. LISP (Response to Robert Eachus's second posting)
Message-ID: <5170@xenna.Encore.COM>
Date: 21 Mar 89 17:02:21 GMT
References: <8903152108.AA06589@zooks.ads.com>
Sender: news@Encore.COM
Reply-To: pierson@mist (Dan Pierson)
Organization: Encore Computer Corp
In-reply-to: rar@ZOOKS.ADS.COM (Bob Riemenschneider)
List-Id: <comp.lang.ada>

In article <8903152108.AA06589@zooks.ads.com>, rar@ZOOKS (Bob Riemenschneider) writes:
>There are exceptions, however.  Based on your latest posting, I take it
>you believe "(apply (read) (read))" to be a specially concocted example,
>intended to make your claim sound dubious.  It wasn't; it was a (simplified) 
>example taken from an actual Lisp application.  (The program supports
>interactive multi-attribute utility analysis.  Rather than having the 
>user supply weights used in a linear combination of utilities across
>attributes, the user is asked for an arbitrary computable function from
>[0,1]^number-of-attributes to [0,1] to be used for combination.  The
>designer (me) has arguments that, for many applications, non-linearity
>is required.)  When time for considering translation to another language
>came around, "(apply (read) (read))"--which, when expanded out to include the
>syntactic analysis of the sexpr read in, etc., made up a goodly chunk of
>the program--was the only really hard part.  Writing a simple Lisp-interpreter
>equivalent was evidently necessary, as you observed.  I asked about
>"(apply (read) (read))" because I wanted to know whether either of the
>AdaLISP submissions you received contained at least a simple interpreter
>of the sort you sketch in your posting.  I still want to know.

My only complaint with this is the assumtion that a Common Lisp
_interpreter_ is the correct (or only solution).  It seems likely that
the computable functions mentioned above would be reused several times
in an analysis session.  Therefore they should run as quickly as
possible and the user should have a way to list the previously entered
functions and reselect one.  This means that "(apply (read) (read))"
might be better expressed as:

    (let* ((form (read))
           (fast (compile nil form)))
      (save-form form fast)
      (apply fast (read)))

Doing this in Ada would require implementing a complete Common Lisp
incremental compiler.  Of course, you could do that, but it hardly
seems worth the effort.

Of course, the functions in the actual application described may be
small enough that the overhead of incremental compilation is greater
than the overhead of interpreting the function.  There are
applications in which incremental compilation is nearly vital, there
are others in which it merely wastes resouces, and there are some in
which is makes sense for the program to initially save the interpreted
form and compile it when and if its usage pattern indicates that
compilation would result in a net savings.
-- 
                                            dan

In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: pierson@encore.com