Re: Ada vs. LISP

[tking@gumby.SRC.Honeywell.COM (Tim King)]

In article <45978@linus.UUCP> eachus@mbunix.mitre.org (Robert Eachus) writes:

>      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. 
>   ...
> (There are certain LISP lexical conventions that are incompatible with
> Ada, but they are easily dealt with: 'a --> QUOTE(A).)

Now, I'm no world class Lisp hacker, but I do know Ada, and I know enough
about Lisp that I almost choked on my tongue when I read this.  I showed
this article to an associate who is heavily involved with Lisp (eg, as a
member of the ANSI Common Lisp standards committee, and as a longtime Lisp
zealot).  He suggested that you might consider the following points:

  1) Lisp's ability to store arbitrary objects in arrays regardless of
     the type of the object (ditto for lists, hash tables, etc.).
  2) The first class nature of functions in Lisp.
  3) Lisp's ability to share state among closures (you might be
     able to do this with Ada tasks).
  4) Lisp macros.
  5) Lisp symbols (they have plists and function bindings).
  6) Lisp's complex type specifiers (e.g. type foo is either an integer or
     an array).
  7) And so on.

In a nut shell Ada can't support Lisp's view of typing, and functions are
not first class objects in Ada.  Even if you could somehow solve these
problems, the performance of the resulting "AdaLisp" would be abysmal.

If you *really* don't have anything better to do, try to write the following
code in Ada:

  (defun funs (n)
    (let ((z n))
      (cons #'(lambda (x) (incf z x))
	    #'(lambda (x) (decf z x)))))

  (setq foo (funs 0))
  (funcall (car foo) 10)   =>  10
  (funcall (cdr foo) 3)    =>   7

(=> is a short hand for evaluates to, and is not part of Common Lisp)

-----------------------------------------------------------------
Tim King                             |
Honeywell Systems & Research Center  |  Are we having fun yet?
Mpls, MN  55418                      |