Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!rutgers!aramis.rutgers.edu!atanasoff.rutgers.edu!lou From: lou@cs.rutgers.edu (lou) Newsgroups: comp.lang.lisp Subject: Re: Virtues of Lisp syntax (a tangent on macros and Scheme) Message-ID: Date: 26 Sep 90 19:18:49 GMT References: <10466@life.ai.mit.edu> <6217@castle.ed.ac.uk> <10722@life.ai.mit.edu> <20501@well.sf.ca.us> <1990Sep18.180829.8801@hellgate.utah.edu> <12812@ists.ists.ca> Sender: lou@atanasoff.rutgers.edu Reply-To: lou@cs.rutgers.edu Followup-To: comp.lang.lisp Organization: Computer Science Dept., Rutgers University, New Brunswick, NJ 08903 Lines: 32 In-reply-to: mike@ists.ists.ca's message of 20 Sep 90 02:46:13 GMT In article <1990Sep18.180829.8801@hellgate.utah.edu> moore%cdr.utah.edu@cs.utah.edu (Tim Moore) writes: >It's not the macros that the application programmers write themselves >that cause problems; at least the programmer knows what the expansions >of those macros look like. Rather, it's the macros that are a part of >the language that cause trouble. Consider how often Common Lisp >programmers use cond, setf, dotimes, dolist, do, and do*. The >expansions of these macros can be pretty hairy. Maintaining the >correspondence between the internal representation of a function and >the form that produced it is not trivial. Here is a case in point, that actually happened to a student in my AI Programming class. He was getting an error message about bad variables in a let, and could not figure out what was going wrong, since the code being executed did not have a let in it! It turns out that in our lisp, prog is implemented as a macro that expands into a form that involves a let. He did have a prog, and the syntax of that prog was bad - not bad enough to prevent the macro expansion but bad enough to cause the let it expanded into to give an error. If the error message were in terms of a prog he would have seen his error quite quickly. In fact he did not, and wasted time on it. On the other hand, using the interactive debugger (and my vast experience :-) I was able to figure it out pretty quickly. But this does point out that any time the code as seen in the debugger / error messages / etc. differs from the code as written by the programmer, there is a price to pay. -- Lou Steinberg uucp: {pretty much any major site}!rutgers!aramis.rutgers.edu!lou internet: lou@cs.rutgers.edu