Subject: Re: weird function behavior From: Erik Naggum <firstname.lastname@example.org> Date: Thu, 16 May 2002 17:33:37 GMT Newsgroups: comp.lang.lisp Message-ID: <email@example.com> * Duane Rettig <firstname.lastname@example.org> | Note here (in Allegro CL): | | CL-USER(2): (defun foo () (eq '(nil) '(nil))) | FOO | CL-USER(3): (foo) | NIL | CL-USER(4): (compile 'foo) | FOO | NIL | NIL | CL-USER(5): (foo) | T | CL-USER(6): | | Again, this does not necessarily show what can be expected, but | what should _not_ be expected. This is a great example to show why the consequences of modifying a literal are _undefined_. Even if it actually works to modify some part of the source code, or some object that is re-created when loading a compiled file, the compiler has a license to coalesce literals because they are not expected to be modified. E.g., a pathological example that may show just how messed up some of these things can get: (defmacro mumble (&body body) (list* 'let '((x '(nil))) body)) => mumble (defun fumble () (mumble (setf (car x) 0))) => fumble (mumble x) => (nil) (fumble) => 0 (mumble x) => (0) I leave it to the reader to figure out why it does not (generally) work with the more normal backquoted form of the macro body. -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief. 70 percent of American adults do not understand the scientific process.