You are right in pointing out that I was not quite precise.  I should
have written something like, `three kinds of special variables that
exist/are specified at program-writing time (compile time).'  (This is
probably not the best formulation.)

Then there is, of course, as you write, the issue of variables being
created at run time.  I mean those created with INTERN, GENSYM, etc.,
whose values are got/set with SYMBOL-VALUE and SETF thereof, and which
are bound with PROGV.

Now things start getting complicated here.  If the list of variable
names given to PROGV is a constant, are the variables not actually
specified at program-writing time?  Or, consider a macro expansion
function that calls GENSYM to produce local variables: what is
run time for the macro expansion function is compile time for the
function containing the macro call.  Or, there may be mixes (whether
desired or not), e.g. when one obtains a string at run time, interns
it, and passes it to SYMBOL-VALUE or PROGV, and the symbol thus
produced happens to be one that appears in a special declaration.

I don't have any ready answers here; it's not that I have no thoughts
on this matter, but if I have to formulate them, I shall need to take
time thinking them over.  In my previous posting, I offered just
a simplification which I believed had some practical value in spite of
not being comprehensive.

I also see now that I am less certain about a terminological issue than
I would like to be.  I must have identified special and dynamic variables
(well, in fact so does the CLHS glossary, but that is not an excuse...).
I am not saying that there should be a semantic distinction, but from a
pragmatic point of view `special' could be taken to imply that the
variable is declared or at least `declarable'---i.e. that it exists at
compile time.  On the other hand, I cannot declare anything about
variables created at run time (well, again we come to the issue that
one program's run time may be another program's compile time).

Well, if one accepts this distinction between `special' and `dynamic'
(I know this might be a big `if'), then PROGV is not about special
variables in this sense of `special,' and the statement in my previous
posting should be taken in this sense.  But this would have excused me
if I had thought about this issue in advance.

I shall be happy to read comments on these matters.

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

Yes, SYMBOL-VALUE of course.  My mistake (was thinking at the same time,
is Linear B a functional language...).

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

To me, the benefit of deep binding is that in a multithreading Lisp
every thread's dynamic bindings are its own.  But let more knowledgeable
people speak on this issue.

Of course, it is well known that you can't have all three operations---
(1) bind a dynamic variable; (2) lookup/set a dynamic variable; (3) change
the dynamic environment (context switch)---in O(1).  I believe support
of multithreading is an important factor as to which tradeoff is to be
preferred.

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

Once again, my `litmus test' for shallow/deep binding is whether it would
affect other threads.

In fact, this realisation cooled my excitement about writing a LETF
macro, which would be something like LET for SETF places---but would
`bind' them only in a shallow way, and have doubtful universal
usefulness.  (Would be implemented similarly to the above macro.)

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

  there may be a reason to use deep binding in a multiprocessing
  environment where you may have to switch contexts very often and this
  should be virtually free.  switching values of a whole bunch of bindings
  in a context switch can get expensive in shallow binding.  I don't know
  if this would actually hold true in any real system or in any real use,
  but it's worth noting that context switching is expensive, and perhaps we
  will find the best solutions in unexpected corners of the solution space.

C-h f letf RET:

: `letf' is a compiled Lisp macro
:   -- loaded from "cl-macs.elc"
: (letf BINDINGS &rest BODY)
:
: (letf ((PLACE VALUE) ...) BODY...): temporarily bind to PLACEs.
: This is the analogue of `let', but with generalized variables (in the
: sense of `setf') for the PLACEs.  Each PLACE is set to the corresponding
: VALUE, then the BODY forms are executed.  On exit, either normally or
: because of a `throw' or error, the PLACEs are set back to their original
: values.  Note that this macro is *not* available in Common Lisp.
: As a special case, if `(PLACE)' is used instead of `(PLACE VALUE)',
: the PLACE is not modified before executing BODY.

If I need a `bindable' global variable, I just have to grin
and bear it.

If I need an unbindable and unchangeable global variable, this
is in fact no variable but a constant, and I have DEFCONSTANT,
with O(1) access time (not to mention possibilities for
optimisation).

Now, the point---what if I need an unbindable but changeable
global variable in Common Lisp (i.e. I don't have DEFGLOBAL)
which is accessible (both for reading and writing) in O(1)?

I can't do (DEFCONSTANT FOO (MAKE-ARRAY NIL)) and then
(AREF FOO) for getting the value and (SETF (AREF FOO) value)  ;ERROR!
for setting the value, though perhaps it would have been nice if
I could.  Using the function value of a symbol (which is changeable
but unbindable) directly is not allowed for arbitrary objects so
the best way I know is to use a closure: use

  (let ((foo init))
    (defun get-foo () foo)
    (defun set-foo (value) (setf foo value)))

and make things look like a real variable by using DEFINE-SYMBOL-MACRO,
defining SETF of GET-FOO, and declaiming GET-FOO and SET-FOO inline.

Is there any better way?

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

 >

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

3.2.2.3 Semantic Constraints
(...)
Constant variables defined in the compilation environment must have a
similar value at run time. A reference to a constant variable in source
code is equivalent to a reference to a literal object that is the value
of the constant variable.

(Well, as Humpty Dumpty said, `There's glory for us!')

So
  (defconstant bad-foo (make-array nil) "single-slot")
  (setf (aref bad-foo) 'bar)
is in error.

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

In one file:

(defconstant +eof+ (list nil))

In another:

(read foo-stream nil nil +eof+)

(I believe that is the right syntax for reading from a stream and having it
return an object rather than signal an error on EOF. In any case, that's
irrelevant to the point.)

Worked as expected in lispworks, but MCL barfed. Apparently, a possible
interpretation of the standard is that the values of contants do not have
to remain eq to each other across different source files. I forget the
exact reasoning, but that is what it came down to. Digitool advised me to
change over to defvar to get around this problem.

In other words, an implementation conforms to the standard if it
re-evaluates and reconstructs a constant's value in each source file. The
idea for the fast global variable, in other words, is not guaranteed to
work in all implementations.

* mike...@mikemac.com (Mike McDonald)
| It says the object, not the contents of the object.

  I think you need to look up `literal object':

literal adj. (of an object) referenced directly in a program rather than
being computed by the program; that is, appearing as data in a quote form,
or, if the object is a self-evaluating object, appearing as unquoted data.
``In the form (cons "one" '("two")), the expressions "one", ("two"), and
"two" are literal objects.''

  such objects are immutable:

constant object n. an object that is constrained (e.g., by its context in a
program or by the source from which it was obtained) to be immutable.  ``A
literal object that has been processed by compile-file is a constant object.''

"The side effects of the execution of defconstant must be equivalent to at
least the side effects of the execution of the following code:

 (setf (symbol-value 'name) initial-value)
 (setf (documentation 'name 'variable) 'documentation)"

Later in the description of defconstant, CLHS says:

"An implementation may choose to evaluate the value-form at compile time,
load time, or both. Therefore, users must ensure that the initial-value can
be evaluated at compile time (regardless of whether or not references to
name appear in the file) and that it always evaluates to the same value."

The CLHS glossary defines "same" as follows (eliding irrelevant
sub-definitions):

"same adj. [...] 2. (of objects if no predicate is implied by context)
indistinguishable by eql. Note that eq might be capable of distinguishing
some numbers and characters which eql cannot distinguish, but the nature of
such, if any, is implementation-dependent. Since eq is used only rarely in
this specification, eql is the default predicate when none is mentioned
explicitly. ``The conses returned by two successive calls to cons are never
the same.'' [...]"

The first sentence seems applicable, since no context (i.e. no statement of
the form "... the same under <predicate>") is given in the definition of
defconstant.

Backing up a bit, I notice the phrase "users must ensure ... and that it
always evaluates to the same value."

Combining this with the final sentence (two conses never the same) of the
"same" glossary entry quoted above, I think I see how your example's
behavior is allowed: If I create a program containing the form
 (defconstant *foo* '(()))
then I have failed to ensure that the initial value is the same at compile
time and load time.  If the implementation evaluates the defconstant form at
both compile and load time, it will cons two different initial values.

So, now for the $2^16 question: Have I interpreted this correctly?

Consider (defconstant *foo* '(())). There are two ways to look at this
constant. The constant exists independent of the source code is one. The
alternative is that the constant is subject to the compile time
environment. As I understand it, the compile time environment does not have
to be the same as the run time environment, which is where forms such as
eval-when come in and play a role. While compiling therefore an
implementation is allowed to reconstruct the value of a constant, rather
than obtain it from some globally correct value. In other words, while
compiling the implementation is allowed to substitute in the value of a
constant and then produce a fasl, rather than look up the value in the
current run-time environment when the compiled code is loaded.

Effectively, this produces a situation where the constant does not preserve
its value across source files. So while the defconstant behaves as the spec
dictates, the result of compiling code containing the constant is counter-
intuitive.

Again, this is coming down through mists of time and ignorance, so a better
informed comment would be very useful.

(defmacro defvassil (var value-form)
  `(define-symbol-macro ,var (load-time-value ,value-form)))

Or, if you prefer:

(defmacro defvassil (var value-form)
  `(define-symbol-macro ,var
     (load-time-value (find-constant-for-vassil ',var ',value-form))))

(defvar *vassil-constants* (make-hash-table))

(defun find-constant-for-vassil (var value-form)
  (multiple-value-bind (constant present-p)
      (gethash var *vassil-constants*)
    (if present-p
        constant
        (setf (gethash var *vassil-constants*)
              (eval value-form)))))

  and?  what part of "literal" don't you get?

---
There is some question as to whether the values produced by references
to DEFCONSTANT are to be treated as literal objects, and are therefore
immutable.  

Two sections indicate that they are to be immutable:

3.2.2.3 Semantic Constraints:

  All conforming programs must obey the following constraints: ...
  Constant variables defined in the compilation environment must have
  a similar value at run time. A reference to a constant variable in
  source code is equivalent to a reference to a literal object that is
  the value of the constant variable.

"constant object" glossary entry

  an object that is constrained (e.g., by its context in a program or
  by the source from which it was obtained) to be immutable. "A
  literal object that has been processed by compile-file is a constant
  object."

Unfortunately, DEFCONSTANT has no direct references to either of these
entries.  In fact, nothing related to DEFCONSTANT seems to reference
this "constant object" entry, which itself doesn't even say anything
about actually applying to DEFCONSTANT.

Furthermore, some sections suggest suggest though ommision that the
value of a constant variable is not a constant object or constant
literal, and these sections should probably be ammended:

DEFCONSTANT dictionary entry:

The entry explains in detail the constraints on changing the values of
the constant variable produced by defconstant, when the value might be
computed, and discusses how the variable may not be bound.  However,
it never says anything about the value being treated as a literal
object, or about references to internal structures of these values.

3.1.2.1.1.3 Constant Variables:

  Certain variables, called constant variables, are reserved as
  "named constants." The consequences are undefined if an attempt is
  made to assign a value to, or create a binding for a constant
  variable, except that a `compatible' redefinition of a constant
  variable using defconstant is permitted; see the macro defconstant.

Note that nothing is said about immutability, nor is there any
reference to constant objects or literal objects.

"constant variable" glossary entry:

  a variable, the value of which can never change; that is, a
  keyword[1] or a named constant. ``The symbols t, nil, :direction, and
  most-positive-fixnum are constant variables.''

Nothing is said about immutability. One could argue either that a
value of a variable never changing means that the binding can't
change, or alterantively that the internal structure of the value
cannot be mutated.  (There is also no reference to section
3.1.2.1.1.3, which is a shame.)

"named constant" glossary entry:

  a variable that is defined by Common Lisp, by the implementation, or
  by user code (see the macro defconstant) to always yield the same
  value when evaluated. "The value of a named constant may not be
  changed by assignment or by binding."

Again, nothing about immutability or treating the value as a literal
object.  (Again, no reference to 3.1.2.1.1.3.)

3.2.1 Compiler Terminology:

  The term literal object refers to a quoted object or a
  self-evaluating object or an object that is a substructure of such
  an object. A constant variable is not itself a literal object.

Because this specifically refers to constant variables, but only in
the negative, this could easily be read as indicating that "the value
of a reference to a constant variable is not itself a literal object."
Apparently, the intention is instead to indicate that the conceptual
object called a constant variable (not its value) is not a literal
object.  However, it is unusual for the spec to refer to the concept
of a variable as an object.

"literal" glossary entry:

  (of an object) referenced directly in a program rather than being
  computed by the program; that is, appearing as data in a quote form,
  or, if the object is a self-evaluating object, appearing as unquoted
  data.

This definition does not include references to a value defined by
DEFCONSTANT.

There is one other source of confusion.  Sunil Mishra gives the
example that some implementations might treat the values of
DEFCONSTANT as compile-file literals, with references in different
files being "similar", but not identical.  This can lead to confusion.
The "workaround" is to use DEFPARAMETER instead, which leads to the
embarrassing situation that a user might tend to think of the value of
a DEFPARAMETER as more "constant" (really more EQ) across files than
the value of a DEFCONSTANT.  This confusion is furthered, as David
Lamkins points out, by generally understanding "similar" to mean EQL.
However, David also points out that the situation only comes up
through "programmer error" because it violates the original citation
from 3.2.2.3, above.  (Any misinterpretatin of Sunil's and David's
statements is my fault, not theirs.)

Ultimately, one wonders what is "the right thing."  Certainly, one
want to allow compilers to treat the value of a constant variable as
some kind of compile-time literal so that partial evaluation can be
performed at compile time for forms involving references.  It comes
down to a quesion of whether DEFCONSTANT constrains both
implementations to make sure that the value was similar at all times,
or just at certain times such as compile and load.

For example, CL already has the issue of what happens when compile
time and run time definitions differ.  Consider an expression like:
  (FOO BAR)

If FOO is an an inlinable reference to the function -, and bar is a
constant variable with value 1, then the compiler is justified in
treating the entire expression as the literal value -1.  This is true
even if the user latter arranges for FOO to have a different function
definition when the above code is actually run.  In fact, a different
reference to (FOO BAR) in a context in which FOO may not be inlined,
must actually call the run time definition of FOO, and might produce a
different result.

In other words, we allow the compiler to freeze in the definitions at
compile time, while still allowing a function binding to change when
referenced in a different context.  In the case of function bindings,
we're still talking about bindings, not internal structure.  (It's
another can of worms as to whether there should be a way to turn of
the constantness of a defconstant BINDING.)  The question here is
whether, in the case of DEFCONSTANT, we can allow internal structure
changes to be picked up at run time.

My own inclination is that we have other mechanisms for disallowing
changes to internal structure -- namely quoting and load-time-value --
which could be used in conjunction with the value-form argument to
DEFCONSTANT if desired.  Thus, why force defconstant to be a bigger
hammer than it needs to be.