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