[Openmcl-devel] User contributions
Ron Garret
ron at awun.net
Wed Jun 17 15:46:47 PDT 2009
On Jun 17, 2009, at 1:15 PM, Dan Weinreb wrote:
>
>
> 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".
>
That's true, but it's a red-herring. You can exhibit the underlying
problem without gensyms. For example:
(eval-when (:compile-toplevel :load-toplevel :execute)
(defconstant foo (get-internal-real-time))
(defun foo () foo)
)
Compile this file, quit Lisp, reload the fasl. No errors, not even
warnings about constants being redefined, and no existentially
ambiguous constructs like uninterned symbols. And yet (equal foo
(foo)) will return NIL with very high probability.
The real problem is not in the meaning of "eq" but rather in the
meaning of "constant." There are two possible meanings:
1. A value that the user can't change
2. A value that the compiler may (but is not obligated to) assume
won't change
The problem is that what I really want is #1, but I can't get it
unless I also accept #2, and #2 causes problems because the compiler
has too much latitude. What's really going on is that the compiler
constant-folds the compile-time value of foo into the compiled version
of #'foo, but not into the definition of the constant foo. The
compiler is free to do so according to the spec, so the above behavior
is technically correct. But behaving correctly is not necessarily the
same as doing the Right Thing IMHO.
rg
More information about the Openmcl-devel
mailing list