Ada vs. LISP

Ada vs. LISP

[Bob Riemenschneider]

=>   From: eachus@mbunix.mitre.org (Robert Eachus)
=>
=>	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! ...

Could you provide more detail?  Handling the "LISP 1.0 subset" is
straightforward.  But how, for example, would the program

			(apply (read) (read))

be written in AdaLISP?

							-- rar

Re: "Forced to Use Ada"

[Bob Hathaway]

In article <470@ajpo.sei.cmu.edu>, eberard@ajpo.sei.cmu.edu (Edward Berard) writes:
>of these posters would be surprised to know that a majority of Ada
>users worldwide use Ada because they want to, not because of any
>mandate. For example, in Europe much more than 50% of the money spent
>on Ada software is spent by those who have no mandate to use Ada,
>i.e., they are free to use any technology they wish.
>

I decided Ada was the best language after independently studying
programming for some time in school.  I had to use C and Pascal in
coursework and after some asking, Modula-2.  So, I was mandated to use
alternative languages although I strongly desired and asked to program
in Ada.  I'm glad to see someone (the government) advocating modern
programming languages along with software engineering; the more support
the better.

Bob Hathaway
rjh@purdue.edu

Re: "Forced to Use Ada"

[A. Jeff Offutt]

From article <6125@medusa.cs.purdue.edu>, by rjh@cs.purdue.EDU (Bob Hathaway):
> ...  I'm glad to see someone (the government) advocating modern
> programming languages along with software engineering; the more support
> the better.

C'mon, be careful what you say.  As a scientist/engineer, I do not want
anybody *mandating* the use of technology without clear *technical* proof
that that is in every case the best solution.

Whether you are an Ada fan, a Modula-II fan, a C fan or even open-minded,
it is very clear that the scientific community is not convinced that
Ada (or any language) is the best technology for all applications.  Or
for any application.
-- 
Jeff Offutt
Department of CS, Clemson University, Clemson SC  (803) 656-5866
Internet:	ofut@hubcap.clemson.edu

Re: "Forced to Use Ada"

[Bob Hathaway]

In article <4624@hubcap.UUCP>, ofut@hubcap.UUCP (A. Jeff Offutt) writes:
> From article <6125@medusa.cs.purdue.edu>, by rjh@cs.purdue.EDU (Bob Hathaway):
> > ...  I'm glad to see someone (the government) advocating modern
> > programming languages along with software engineering; the more support
> > the better.
> 
> C'mon, be careful what you say.  As a scientist/engineer, I do not want
> anybody *mandating* the use of technology without clear *technical* proof
> that that is in every case the best solution.
> 
> Whether you are an Ada fan, a Modula-II fan, a C fan or even open-minded,
> it is very clear that the scientific community is not convinced that
> Ada (or any language) is the best technology for all applications.  Or
> for any application.
^^^^^^^^^^^^^^^^^^^^^^
> -- 
> Jeff Offutt

Its not the language which is important its the facilities it provides.  
Does any of the above languages provide all of the necessary and desirable
constructs to provide well designed software and a method for validating
correct compilers?  What other language provides concurrency, dynamic
exception handling, generics, reasonable encapsulation constructs, Adts,
complete control structures, variable number of parameters with defaults,
etc; there are some languages which don't even provide the basics
for well designed software such as a reasonable type system or dynamic
memory management (ie. ForTran) or strong typechecking and choice of 
parameter modes (C), etc.  Ada was designed to standardize software and it
could replace almost any language with exceptions being rare.  For
scientific software, Ada provides Adts to model vectors, matrices, and other
mathematical objects and operators can be overloaded to provide high quality
code.  Ada's methodolgy is an excellent base for well designed software; as
a scientist/engineer what doesn't Ada provide for you?  Even if other
reasonably complete languages could be standardized and validated I wouldn't
want to learn X number of languages to read other programmers code,
the fewer languages the better.  While research languages will continue to
explore new ideas, it will be several years before another language replaces
Ada.  I can't think of any application Ada is poorly suited to with its
emphasis on well engineered software, can you justify your underlined claim
above?

Bob Hathaway
rjh@purdue.edu

Re: "Forced to Use Ada"

[Paul Raveling]

In article <6153@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes:
>In article <4624@hubcap.UUCP>, ofut@hubcap.UUCP (A. Jeff Offutt) writes:
>> 
>> C'mon, be careful what you say.  As a scientist/engineer, I do not want
>> anybody *mandating* the use of technology without clear *technical* proof
>> that that is in every case the best solution. ...
>
>Its not the language which is important its the facilities it provides.  
>Does any of the above languages provide all of the necessary and desirable
>constructs to provide well designed software and a method for validating
>correct compilers?  What other language provides concurrency, dynamic
>exception handling, generics, reasonable encapsulation constructs, Adts,
>complete control structures, variable number of parameters with defaults,
...
>...  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?

	Standardization is precisely the greatest danger of ADA,
	particularly because the DOD standard doesn't even permit
	extensions.  If we accept the ADA standard we lose the
	option to improve as we learn better ways to approach
	software engineering.

	As for technical merit, there's plenty of room for argument.
	Much of it is in the realm of religion for now, but what's
	clear is that there's no clear agreement.  Having written
	a compiler for an ADA subset, I know of a number of things
	I'd do differently in the language design if the opportunity
	existed.  I'm not fond of ADA -- neither am I utterly pleased
	with C, FORTRAN, PL/I and relatives, ALGOL-60, COBOL, and
	gobs of other languages.
	
	Suppose somone designed a language provably better than these --
	if we mandate an existing standard, such as ADA or C, we risk
	preserving a dinosaur at the expense of suffocating mammals.
	That's my usual comment about UNIX, but it also suits languages.


----------------
Paul Raveling
Raveling@isi.edu

Ada vs. LISP

[Robert Eachus]

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;

Re: Ada vs. LISP

[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                      |

Re: Ada vs. LISP

[John Gateley]

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

Re: Ada vs. LISP

[Robert Eachus]

     I recieved many responses to my posting about Lisp style
programming in Ada.  Some were a bit extreme--An Ada program which
supports the LISP semantics for (apply (read) (read)) is called a
LISP interpreter.  That is not what I was talking about.  Of course
you can write a LISP _interpreter_ in Ada, I was talking about
compilable Ada code derived from LISP programs or designs.

     Now that I have also recieved several civil responses asking
how to do it, it seems I had better post an example or two.  This
posting won't satisfy the skeptics, but then I could probably write
a book explaining all the details and not satisfy some of them.

     The first thing to realize is that, contrary to the way Ada
generics are usually taught, instantiation of generics happens during
program execution, and that each time the generic instantiation is
elaborated it creates a new instance. (If you think you understand
this, skip ahead to SKIP_TO_HERE:. But I warn you, most Ada
programmers only think they understand what that meant.)

     Those of you who are left, try this on your favorite Ada
compiler:

     generic
       type Element is private;
       type Index is range <>;
       type List is array(Index) of Element;
     function Reverse(L: List) return List;

     function Reverse(L: List) return List is
       R: List; -- OK since List is constrained;
     begin
       for I in L'RANGE loop
         R(I) := L(L'LAST - (I - L'FIRST));
       end loop;
       return R;
    end Reverse;

    There are more elegent ways to write this in Ada, but that is not
the point.  If you write a program to instantiate this generic in a
loop:

    with Text_IO; with Reverse; with Get;
    procedure Test is
    begin
      loop
        declare
          Foo: constant String := Get;
          subtype Foo_Index is Integer range Foo'FIRST..Foo'LAST;
          subtype Foo_Type is String(Foo_Index);
          function Backwards is new Reverse(Character, Foo_Index, Foo_Type);
        begin
          exit when Foo'LENGTH < 1;
          Put_Line(Backwards(Foo));
        end;
      end loop;
    end Test;

    On every pass through the loop, subtype Foo_Type has different
bounds.  Therefore each instance of Backwards expects a different
length string.  (Defining the function Get using TEXT_IO.GET_LINE is
left as an exercise for the reader.)

SKIP_TO_HERE:

    Now most of you are probably saying: "Big deal, we knew that Ada
allowed strings with non-static bounds...", but the big deal is that
subprograms are allowed as generic formals:

    generic
      type Element is private;
      type List is private;
      with function Something (E: in Element) return Element;
      with function "&"(Left: Element; Right: List) return List;
      with function CDR(L: in List) return List;
      with function CAR(L: in List) return Element;
      NUL: List
      -- Note: in a "real" lisp style Ada program only "Something"
      -- would be a generic parameter.
    function MAPCAR (L: in List) return List;

    function MAPCAR (L: in List) return List is
    begin
      if L = NUL then return NUL; end if;
      return Something(CAR(L)) & MAPCAR(CDR(L));
    end MAPCAR;

    Very useful, but not yet LISP.  We sometimes need to be able to
pass functions as objects.  Fortunately there is a way, but Ada
purists will scream:

    function MAPCAR (L: in List; F: SYSTEM.ADDRESS) return List is
      function Something (E: in Element) return Element;
      pragma INTERFACE(System, Something);
      for Something'ADDRESS use F;
    begin
      if L = NUL then return NUL; end if;
      return Something(CAR(L)) & MAPCAR(CDR(L));
    end MAPCAR;

    Obviously not guarenteed to be portable, but if your compiler
supports it, you don't even need to use generics to have (LISP) fun
in Ada.  (Just substitute whatever language name your compiler
requires for System in the pragma.  One or two even allow Ada!)

    The next level of completeness is to create a "real" LISP
environment.  It is very rare to need to go this far, but it is
possible: 

    package LISP is
      type Element is private;

      type List is  array (Natural range <>) of Element;
      -- Lists are defined as arrays so that (a,b,c) works. I usually
      -- cheat and provide visible arrays of Integers, and Float so
      -- that (1,2,3) and (1.0,2.0,3.0) can be recognized and
      -- handled.

     type Element_Type is (Number, Character, Symbol, List, Vector,
                    	   Structure, Function);
      -- You may wish to add others, but this is what I use.  Note
      -- that this is actually only provided as a shortcut for a
      -- special form of my own: 

      function IS_A(Object: Element; Class: Element_Type) return Boolean;

      function MAKE(I: Integer) return Element;
      function MAKE(C: Character) return Element;
      function MAKE(S: String) return Element;
      -- etc.

      NIL: constant Element;

      Apply: Element;
      Eval: Element;
      -- Through all the special forms you use...
    private
      type Object;
      type Element is access Object;
    end LISP;

    What about the package body?  It's fairly simple: Eval looks for a
predefined functions with a case statement, and otherwise follows the
standard (LISP) rules, and so on.  Defun (and this is what keeps
things from being unacceptably slow) actually does instantiation, and
keeps the defined form available for Eval (see above).  If pragma
INTERFACE didn't work, you could treat each new function as a new Ada
task object but I have had to stoop that low.  I prefer to make
available several generics in the specification of package LISP:

    generic
      with procedure X(L: List);
    package New_Procedure is
      New_X: Element;
    end package;

    New_X is, of course a new function object which can be Evaled,
and the semantics are to invoke (the Ada generic formal procedure) X
on the first argument.  (In this case it evals to nil, of course.)
This allows some functions (or in this case a procedure) to use Ada
semantics, and others to use LISP.

					Robert I. Eachus

Re: Ada vs. LISP

[Steven D. Litvintchouk]

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.