[Openmcl-devel] User contributions

[Dan Weinreb]

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
met.

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.