[Openmcl-devel] User contributions
dlw at itasoftware.com
Wed Jun 17 13:15:12 PDT 2009
Ron Garret wrote:
> The invariant that I want to maintain is that the result of any
> reference to +guardian+ (or (+guardian+) or whatever) is always EQ to
> any other such reference or call, and always NOT eq to the result of
> any computation that does not reference or call +guardian+. And this
> invariant must hold regardless of any intervening operations (i.e.
> file compilations and load, assignments, etc.)
Well, if you mean this for the scope of a single Lisp world, then
you could just do
(defvar +guardian+ (list))
If you call compile-file or load or setq, as long as the
symbol +guardian+ is not affected, your invariant is
If you mean a scope larger than a Lisp world, there's a deep issue
of what you mean by "eq".
> It doesn't matter whether operations that would cause the invariant to
> be broken result in an error (like trying to rebind a constant), or if
> such operations are merely impossible (like trying to reassign a
> closed-over value in the absence of an explicit provision for do such
> a reassignment).
> BTW, just for perspective, this makes a very interesting intellectual
> exercise, but it's not all that important for my purposes. I'm
> content to work around the problem by simply using an interned symbol
> with a very obscure name. But I do think there's an argument to be
> made that allowing:
> (defconstant foo ...)
> (defun foo () foo)
> (eq foo (foo))
> to return NIL is a bug in the spec.
Of course it will never return nil if you simply evaluate
these three forms with a single Lisp world. The problems
arise when you are crossing Lisp worlds, because you
have one Lisp that compiles a file into a fasl and
then a second Lisp that reads the fasl.
If you first evaluate (defconstant foo (gensym))
and then you load in a file whose source
contained that same form, you are violating the
rule that says that a subsequent defconstant
of the same symbol must have the same value.
More information about the Openmcl-devel