Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!rutgers!cmcl2!lanl!opus!ted
From: ted@nmsu.edu (Ted Dunning)
Newsgroups: comp.sw.components
Subject: Re: Lisps
Message-ID: 
Date: 29 Sep 89 00:47:06 GMT
References:  <6617@hubcap.clemson.edu>
Sender: news@nmsu.edu
Organization: NMSU Computer Science
Lines: 36
In-reply-to: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu's message of 28 Sep 89 00:48:48 GMT


In article <6617@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:


   From ted@nmsu.edu (Ted Dunning):
   > trivial and lucid in lisps that support continuations and/or engines.
   > try scheme, allegro common lisp, symbolics common lisp, or xerox's
   > interlisp offerings.  

       I take it the Lisp community does not value portability...
       what happens when you want to take code from one manufacturer's
       Lisp and compile it on a different system?

referring to lisp as a single language is a serious error.  it is a
family of languages, much as the algol family is.  lisp includes
interlisp, common lisp, scheme, t, ml and many others.  the algol
family includes algol, pascal, c, bcpl, ada and all of the modulas as
well as many others.

if you are using common lisp, then programs will generally port very
easily from vendor to vendor.  if you take a scheme program and try to
compile it with a zeta-lisp compiler, then you will have about as much
luck as compiling ada with a c compiler.  does this mean that ada
users are not concerned with portability?  of course not.

       Also: how about exception handling?

what about it?  catch/throw with unwind-protect is a pretty powerful
and clean mechanism.  it is also ubiquitous among the various lisps.
various other exception handling systems have been implemented on top
of it.

--
ted@nmsu.edu
			remember, when extensions and subsets are outlawed,
			only outlaws will have extensions or subsets