Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!uunet!mcvax!ukc!etive!aiai!jeff From: jeff@aiai.ed.ac.uk (Jeff Dalton) Newsgroups: comp.lang.lisp Subject: Re: Unix Lisp Environments (why the slow evolution) Message-ID: <421@skye.ed.ac.uk> Date: 8 May 89 17:37:05 GMT References: <7802@zodiac.UUCP> Reply-To: jeff@aiai.UUCP (Jeff Dalton) Organization: AIAI, University of Edinburgh, Scotland Lines: 34 In article roberts@studguppy.lanl.gov (Doug Roberts) writes: I think, however, that you missed one of the major reasons that the Unix LISP environment is still decidedly inferior to a LISPm: the majority of the market that is considering LISP as a language in which to deliver applications is currently a member of either the Unix or the VMS community: _they are not aware of the productivity that exists on a LISPm_. I think you have identified an important point. However, I would guess that most of the people who implement Lisps for Unix (Lucid, Franz Inc, at al) do have a fairly good idea of what the Lisp Machines accomplish. So why don't they provide the same thing on conventional machines? I think it's possible to provide environments that are very similar. People here who use Inference ART (Automated Reasoning Tool, or something like that), which is built on top of Lisp, report that the ART environment on a Sun is very close to that on a Symbolics, although at the Lisp level the debugger probably isn't as good. However, possible is not the same as easy, and I suspect the Lisp implementors have not had sufficient resources to let them prepare environmental tools as soon as they'd have liked. Indeed, I think it is often easier to develop tools for languages, such as C, that are more straightforwardly based on files, statements, and lines of code. On Suns, for example, dbxtool can get some very useful effects simple by displaying the relevant lines of a source file. Most Lisp debuggers find it very difficult to relate evaluation to source code, and this is perhaps a greater problem in Common Lisp because so much tends to be done by macros. Macro expansions often look very little like what the user wrote. This can be true in C as well, but most of the time it doesn't matter, because the debugger works with lines of source rather than with individual expressions.