chandra@uiucuxc.Uiuc.ARPA (08/08/85)
HELP: A strange Bug! I got an exprimental lisp from a friend to play with. It has a strange bug. Here is a session which illustrates the bug. Notice how the variable foo gets changed after the eval is called. ==> (defun test macro (args) `(cdr (quote ,(cadr args)))) test ==> (test (a b c d)) (b c d) ==> (setq foo '(test (a b c d))) (test (a b c d)) ==> (eval foo) (b c d) ==> foo (cdr '(a b c d)) ; why did the foo change? I tried the same thing in real MAClisp and Franz ; and the value of foo was retained and was not changed. ; Have you got any idea what went wrong? Thank you Navin Chandra (to reply: please post a response on the net.lang.lisp, mail never really seems to reach me)
ags@pucc-h (Dave Seaman) (08/09/85)
In article <16700002@uiucuxc> chandra@uiucuxc.Uiuc.ARPA writes: > > HELP: A strange Bug! > >I got an exprimental lisp from a friend to play with. It has >a strange bug. [ Sample session shows (setq foo '<a macro call>) followed by (eval foo) leaves foo set to the expanded form of the macro.] This is not a bug. It's a feature. I don't know how your lisp works but in Franz lisp you can enable this feature by setting the special symbol 'displace-macros' to a non-nil value (this feature is turned off by default, at least on our system.) The idea is that it is more efficient to expand macros only once. -- Dave Seaman ..!pur-ee!pucc-h:ags
hedrick@topaz.RUTGERS.EDU (Chuck Hedrick) (08/11/85)
You report that a macro was replaced by its expansion. This is probably not a bug. Several versions of Lisp do this intentionally. It saves the time of expanding the macro each time the form is evaluated. WIth systems that are interpreted, and use a lot of macros, the time saving can be dramatic. In case you wonder how it is changing the value of the variable, probably it is not. That is, the new expression is probably EQ to the old one. It just has its CAR and CDR changed to new values. This technique is used so that in case the form is embedded in the middle of something else, all pointers now point to the new form.
choy@whuts.UUCP (CHOY) (08/12/85)
> > HELP: A strange Bug! > > I got an exprimental lisp from a friend to play with. It has > a strange bug. > Here is a session which illustrates the bug. Notice how > the variable foo gets changed after the eval is called. > > ==> (defun test macro (args) `(cdr (quote ,(cadr args)))) > test > > ==> (test (a b c d)) > (b c d) > > ==> (setq foo '(test (a b c d))) > (test (a b c d)) > > ==> (eval foo) > (b c d) > > ==> foo > (cdr '(a b c d)) > > ; why did the foo change? I tried the same thing in real MAClisp and Franz > ; and the value of foo was retained and was not changed. > > ; Have you got any idea what went wrong? > > Thank you > Navin Chandra > (to reply: please post a response on the net.lang.lisp, mail never > really seems to reach me) This is not a bug. This is a feature to save you some computation. Remember "test" is a macro. When you evaluate the expression "(test (a b c d))", it will be expanded to "(cdr '(a b c d))" and your lisp interpreter replace the original expression to the expanded expression. Therefore, no expansion need to be done next time. In Franz Lisp, there is a flag to turn on and off the replacement from the original expression to the expanded expression. By the way, does anybody know how to make a single symbol as a macro token? I mean the original expression will be "symbol" instead of "(symbol)".
willc@tekchips.UUCP (Will Clinger) (08/12/85)
Chandra's interpreter appears to be modifying source code destructively whenever it expands a macro. That means it has to expand the macro only once, instead of every time it interprets the macro call. The various Lisp machine interpreters do this for macros that the programmer has declared to be "splicing" macros, but they don't do it for ordinary macros because most users don't like it when the system trashes their source code. William Clinger Tektronix
scent@sask.UUCP (Scent Project) (08/13/85)
> > HELP: A strange Bug! > > I got an exprimental lisp from a friend to play with. It has > a strange bug. . . . > Navin Chandra > (to reply: please post a response on the net.lang.lisp, mail never > really seems to reach me) Well, I've only used Franz LISP, so this may be totally wrong--take it with a grain of salt. I beleive there are some LISP's which, when they do a macro expansion, actually go right in and modify LISP structures--in other words, they don't just return the expanded macro, they actually replace the macro with its expansion, in the code the macro was called from. I'm not sure if this would work all the time (it will take a bit of deeper thought on my part), but I think I do recall reading something to this effect. So, your bug may not be a bug at all. Ken McDonald
martillo@csd2.UUCP (Joachim Martillo) (08/13/85)
Original article follows. This is not necessarily a bug. I do not know what dialect of lisp you are using but in many lisps (e.g. Common Lisp) the actual point at which a macro expansion is supposed to replace the macro invocation is unspecified. Apparently this dialect of lisp substitutes the expansion for the macro call at the first invocation of eval on the form. /* csd2:net.lang.lisp / chandra@uiucuxc.Uiuc.ARPA / 10:32 am Aug 8, 1985 */ HELP: A strange Bug! I got an exprimental lisp from a friend to play with. It has a strange bug. Here is a session which illustrates the bug. Notice how the variable foo gets changed after the eval is called. ==> (defun test macro (args) `(cdr (quote ,(cadr args)))) test ==> (test (a b c d)) (b c d) ==> (setq foo '(test (a b c d))) (test (a b c d)) ==> (eval foo) (b c d) ==> foo (cdr '(a b c d)) ; why did the foo change? I tried the same thing in real MAClisp and Franz ; and the value of foo was retained and was not changed. ; Have you got any idea what went wrong? Thank you Navin Chandra (to reply: please post a response on the net.lang.lisp, mail never really seems to reach me) /* ---------- */
darrelj@sdcrdcf.UUCP (Darrel VanBuer) (08/15/85)
Interlisp has generally replaced macros and clisp expressions by their
translations (macro replacement is a relatively new feature), but you have
to work fairly hard to see it since both the pretty-printer and the editor
plays games to show you the "real" source (hiding in a hash array, or
occasionally in line).
--
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,orstcs,sdcsvax,ucla-cs,akgua}
!sdcrdcf!darrelj
VANBUER@USC-ECL.ARPA