Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!odi!dlw From: dlw@odi.com (Dan Weinreb) Newsgroups: comp.lang.lisp Subject: Re: Unix Lisp Environments (why the slow evolution) Message-ID: <352@odi.ODI.COM> Date: 17 May 89 20:23:05 GMT References: <7802@zodiac.UUCP> <421@skye.ed.ac.uk> Organization: Object Design Inc., Burlington, MA Lines: 25 In-reply-to: jeff@aiai.ed.ac.uk's message of 8 May 89 17:37:05 GMT In article <421@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes: 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. Yes, the reason it's hard in Lisp is entirely due to macros. Look at the Symbolics debugger: when it is operating on C, Fortran, or Pascal code, it works completely correctly with the original source code (and works a whole lot better than dbxtool, by the way). But doing the same for Lisp is significantly harder, because Lisp macros are so powerful. It's a tradeoff: it is harder to write a source-level debugging for an extensible language like Lisp than for a fixed language like C. Of course, Lisp's extensibility (arising from macros) is one of the biggest advantages of the Lisp language. C macros are much wimpier, and therefore easier to deal with. Still, the fact that the C debuggers cannot handle macros can be a true pain in the neck, as I've discovered in practice.