eachus@mbunix.mitre.org (Robert Eachus) (03/07/89)
In article <7682@venera.isi.edu> raveling@vaxb.isi.edu (Paul Raveling) writes: >In article <6153@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes: >>... Ada was designed to standardize software and it >>could replace almost any language with exceptions being rare. > > Have you suggested that to a hard-core LISP user lately? > >Paul Raveling >Raveling@isi.edu 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! Not only can you write AdaLISP, but some people already do. Incidently, AdaLISP does look a lot like LISP with the primary structures being nested fuction calls and aggregates, but there is no easy way to close lots of scopes, so don't try it without a good EMACS. It seems that everyone has seen AdaTRAN, but few people realize that the capability to write FORTRAN or COBOL or Pascal or LISP style programs in Ada was not an accident, it was a deliberate design requirement. Robert I. Eachus function TWIDDLE_THUMBS (LEFT, RIGHT: THUMB) return THUMBS is begin return TWIDDLE_THUMBS(RIGHT, LEFT); end TWIDDLE_THUMBS;
tking@gumby.SRC.Honeywell.COM (Tim King) (03/10/89)
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 |
gateley@m2.csc.ti.com (John Gateley) (03/10/89)
In article <45978@linus.UUCP> eachus@mbunix (Robert I. 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. Hmmm.... how would the following programs be written in Ada: (I give both Scheme and CL versions, take your pick) Scheme CL (define x (defun x (n) (lambda (n) (function (lambda (m) (lambda (m) (+ n m))) (+ m n)))) that is, how can you write first class functions? These are quite useful for things like writing an interpreter for Lisp in Lisp, or a denotational semantics, or table abstractions where the elements are functions etc. Scheme CL (define print (defun print (x) (lambda (x) (typecase x (cond (integer 1) ((integer? x) 1) (real 2) ((real? x) 2) (complex 3) ((complex? x) 3) (vector 4))) ((vector? x) 4)))) that is, how can you write dynamically typed functions? I do not think you can. These two features of Lisp that I have highlighted are fundamental aspects of the langauge. That is, it is not fair to say that you can translate programs from Lisp to Ada unless you can handle these cases as well. I am assuming that you do not mean you can write a Lisp compiler in Ada (since you can do that in any language), but that you can translate any expression in Lisp into a corresponding Ada fragment. John gateley@tilde.csc.ti.com
sdl@linus.UUCP (Steven D. Litvintchouk) (03/13/89)
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.... > It seems that everyone has seen AdaTRAN, but few people realize > that the capability to write FORTRAN or COBOL or Pascal or LISP style > programs in Ada was not an accident, it was a deliberate design > requirement. Now how about Simula-67? If only you had applied the same requirement to translating Simula-67 programs to Ada, perhaps Ada might have supported subclassing/inheritance better than it does! Seems like a missed opportunity.... In fact, the significance of Simula-67's class mechanism appears to have been overlooked by nearly everyone connected with the DoD HOL initiative--was it ever seriously considered for inclusion in Steelman? Or did they conclude (mistakenly) that types accomplished exactly the same thing? Steven Litvintchouk MITRE Corporation Bedford, MA 01730 Fone: (617)271-7753 ARPA: sdl@mitre-bedford.arpa UUCP: ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl "Those who will be able to conquer software will be able to conquer the world." -- Tadahiro Sekimoto, president, NEC Corp.