[Openmcl-devel] User contributions
dlw at itasoftware.com
Fri Jun 19 11:09:25 EDT 2009
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.
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
>> 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.
More information about the Openmcl-devel