[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