billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (09/28/89)
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? Also: how about exception handling? Bill Wolfe, wtwolfe@hubcap.clemson.edu
tynor@prism.gatech.EDU (Steve Tynor) (09/28/89)
Bill "Ada - the One True Language" Wolfe writes: >From ted@nmsu.edu (Ted Dunning): > 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? Get your head out of your, ahem, ARM - learn about the world outside Ada. Common Lisp is quite standardized, thank you. We port code between various machines regularly with very little difficulty (user interface issues mostly - you can't blame CL for that!) > Also: how about exception handling? Read about it. Lookup unwind-protect, catch and throw. Lisp has had exception handling for years (decades). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= (require 'disclaimer) Steve Tynor Georgia Tech Research Institute Artificial Intelligence Branch tynor@prism.gatech.edu
ted@nmsu.edu (Ted Dunning) (09/29/89)
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
fischer@iesd.auc.dk (Lars P. Fischer) (09/29/89)
>> 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... Please remember that Lisp is the name of a family of programming languages, not a specific language (compare this with the family of Algol- and Pascal-like languages). The Lisp family boast a vast range of languages, some very much alike, some not. Like the Algol family, the Lisp-family has had it's share of standardization efforts (e.g. Common Lisp), attempts at OOPL (CLOS, Loops, ...), etc. The Lisp family is constantly evolving, producing new variants all the time, some with fancy features, some different because of different points of view, etc. (Can you say "Modula3", "Oberon", "YouNameIt"). Programming languages just are like that, Q: Why can't I run my Scheme program with a Common Lisp system. A: Same reason your C compiler won't compile your Ada program. > what happens when you want to take code from one manufacturer's > Lisp and compile it on a different system? If they are both, say, Common Lisp systems, thing will be OK (provided you didn't use X11 or something nasty like that...). > Also: how about exception handling? Catch! /Lars -- Copyright 1989 Lars Fischer; you can redistribute only if your recipients can. Lars Fischer, fischer@iesd.auc.dk, {...}!mcvax!iesd!fischer Department of Computer Science, University of Aalborg, DENMARK. "I could have done it in a much more complicated way", said the Red Queen, immensely proud. -- Lewis Carrol, Alice in Wonderland
lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (09/30/89)
In article <FISCHER.89Sep29042207@jacquard.iesd.auc.dk> fischer@iesd.auc.dk (Lars P. Fischer) writes: >The Lisp family boast a vast range of languages, some very much alike, >some not. Like the Algol family, the Lisp-family has had it's share of >standardization efforts (e.g. Common Lisp), attempts at OOPL (CLOS, >Loops, ...), etc. Though correct from a researcher's point of view, this strikes me as somewhat misleading to an industrial user, particularly in the United States. The future - and for the most part, even the present - of US industrial Lisp *is* for all practical purposes Common Lisp, the language undergoing ANSI standardization. Major vendors are not building new industrial-strength systems on any other dialect, nor are major industrial users planning new purchases of any other. Extensions are welcomed (though they are not to be used in portable code); subsets and variants are rejected. First-generation object-oriented programming systems have been useful both for proving concepts and for building systems, but again, the future is in the second generation: the Common Lisp Object System, subject of ANSI standardization. If this is not a generally fair summary of US industrial Lisp usage, please let me know. I grant that the situation in research and teaching is significantly different: Theoretical and pedagogical considerations are given great weight, as one would expect. Scheme, in particular, is quite popular on college campuses. >The Lisp family is constantly evolving, producing new variants all the >time, some with fancy features, some different because of different >points of view, etc. (Can you say "Modula3", "Oberon", "YouNameIt"). This is a description of research, but not of industrial practice. It is true, however, that even Common Lisp will evolve at a faster rate than languages such as C and Ada, simply because Lisp's syntax and semantics are specifically *designed* for extension. Luckily, those same facilities of Lisp make back-compatibility easier as well. >If they are both, say, Common Lisp systems, thing will be OK (provided >you didn't use X11 or something nasty like that...). Yes, a graphics standard for Common Lisp is still "emerging." Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.