Re: Ada vs. LISP (Response to Robert Eachus's second posting)

Re: Ada vs. LISP (Response to Robert Eachus's second posting)

[Bob Riemenschneider]

Robert:

Thanks for posting the examples.  While they may not "satisfy the skeptics",
they make the details of your claims for AdaLISP considerably clearer.  It
now seems to me that most of the "extreme" reaction was due to a 
misinterpretation of your original claim.

=>	One of the things which I did during the ANSI standardization of
=>   Ada was to look for ANYTHING in the standard which would make
=>   translation of LISP programs into Ada difficult.  There were a few
=>   problems in the early drafts, but they were all eliminated by the
=>   final draft.  As one of the problems for the AdaCan contest I proposed
=>   writing a compatiblity package to allow transliterated Common LISP to
=>   be compiled by any Ada compiler.  (There are certain LISP lexical
=>   conventions that are incompatible with Ada, but they are easily dealt
=>   with: 'a --> QUOTE(A).)  
=>
=>	The problem was eliminated from the final list as too easy, but I
=>   still recieved two proposed solutions from LISP and Ada programers I
=>   showed the writeup to! ...

I now understand you to be claiming that the bulk of most Lisp application
programs can be easily rewritten in Ada given a fairly small collection of
fairly simple library packages.  I've had some experience porting Lisp
applications to Ada, and, based on that experience, I certainly agree.
(In fact, as your examples show, it's easier to "transliterate" Lisp into 
Ada than into, say, Pascal.) 

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.

I think if you re-read the passage I quoted above, you'll see that it
could be understood as saying that translation of virtually *any* Common 
Lisp program into Ada is easy, since you never explicitly restrict the class
of Lisp programs you're discussing.  The point of most of the "uncivil"
replies is that that's false, because some programs would require writing a 
Common Lisp interpreter in Ada, and writing a *Common* Lisp interpreter in 
any language is *hard*.  You seem to be well aware of this, and, perhaps
justifiably, to take offense at replies that suggest that you aren't.
On the other hand, Lisp proponents are ever more frequently having to
argue that *some* applications are orders of magnitude easier to
program in Lisp than in Ada, attempting to justify it's use to someone
who doesn't have any idea what Lisp is or why this is the case.  Every
time someone posts a message to comp.lang.ada that *can* be interpreted
as saying "there's never any significant advantage in using Lisp rather
than Ada", some people who do (or want to) believe that will take the
posting as evidence that that's the case.  So, you've made Lisp proponents'
lives more difficult, and some of them, understandably, got upset.  

You might have some disagreement with Lisp proponents as to which
applicaions are better coded in Lisp than Ada, but I think everyone
agrees that Lisp has no great advantage when it comes to simple list 
processing, and that it has a big advantage when a full-blown Common
Lisp interpreter is needed.  I'd be very interested in seeing Ada fans
address some of the features on Tim King's list, in the way that Mike
Linnig addressed John Gateley's dynamic typing example.

							-- rar

Re: Ada vs. LISP (Response to Robert Eachus's second posting)

[Robert Eachus]

In article <8903152108.AA06589@zooks.ads.com> rar@ZOOKS.ADS.COM (Bob Riemenschneider) writes:

>Thanks for posting the examples.  While they may not "satisfy the skeptics",
>they make the details of your claims for AdaLISP considerably clearer.  It
>now seems to me that most of the "extreme" reaction was due to a 
>misinterpretation of your original claim.

     Glad to be back in a rational discussion.

>There are exceptions, however.  Based on your latest posting, I take it
>you believe "(apply (read) (read))" to be a specially concocted example...
(lots deleted).

     No, I believe it is an example of a problem that requires an
interpreter.  If you use a compiler for such an application, you (as
you noted) end up writing your own interpreter.  This issue is
different from choice of language, although they are interdependant.
I have BASIC(ugh!, but a nice graphics interface), Scheme and APL
interpreters on my Amiga for that sort of stuff, and I am planning to
get Maple for more sophisticated math munging.  If the result is
something I need to encapsulate for others to use and (horrors)
maintain, I use a compiler, and usually a different language.  The
language switch is usually a non-issue, because a total rewrite is
required anyway.  If it isn't, it means that the requirements haven't
changed drastically and I can stay with an interpreted version.

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

Re: Ada vs. LISP (Response to Robert Eachus's second posting)

[Dan Pierson]

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