[Openmcl-devel] User contributions

[Dan Weinreb]

Yes, I agree completely.  Well put.

So the practical advice is that the value form of a defconstant
must be a form that is idempotent, and it's probably also
a very good idea for that form to have no side effects.
This is a recommended convention that cannot (easily)
be enforced.  I'm adding this to our style guide.

-- Dan

Ron Garret wrote:
>
> 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
>