Re: weird function behavior - Naggum cll archive

Subject: Re: weird function behavior
From: Erik Naggum <erik@naggum.net>
Date: Thu, 16 May 2002 17:33:37 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3230559216909207@naggum.net>

* Duane Rettig <duane@franz.com>
| 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.