http://www.lispworks.com/reference/HyperSpec/Body/f_consta.htm  says:

    The following kinds of forms are considered constant forms:

    * Self-evaluating objects (such as numbers, characters, and the
      various kinds of arrays) are always considered constant forms
      and must be recognized as such by constantp.

Clearly, an array is not a constant (for example, in clisp):

[4]> (setq a (make-array 4))
#(NIL NIL NIL NIL)
[5]> a
#(NIL NIL NIL NIL)
[6]> (constantp a)
T
[7]> (setf (aref a 1) 'a)
A
[8]> (constantp a)
T
[9]> a
#(NIL A NIL NIL)
[10]> (setq b a)
#(NIL A NIL NIL)
[11]> (setf (aref a 0) 'b)
B
[12]> b
#(B A NIL NIL)
[13]> a
#(B A NIL NIL)
[14]> (eq a b)
T

http://www.lispworks.com/reference/HyperSpec/Issues/iss084_w.htm  says:

    The description of CONSTANTP in the draft standard (version 8.81)
    contained a bug because it did not acknowledge that (QUOTE xxx)
    would reliably be detected as a constant by CONSTANTP. The amended
    text of the definition, which is the current definition in the
    draft specification at the time this proposal is written, says:

    CONSTANTP object [Function]

    Returns <true> if its argument can be determined by the
    <implementation> to be a <constant form>; otherwise, it returns
    <false>.

    The following items are considered constant forms:

    * <constant objects> (such as <numbers>, <characters>, and
      the various kinds of <arrays>) are always considered
      <constant forms>.

While CLtL says:

    The specification of CONSTANTP in CLtL says:

    CONSTANTP object [Function]

    If the predicate CONSTANTP is true of an object, then that object,
    when considered as a form to be evaluated, always evaluates to the
    same thing; it is a constant. This includes self-evaluating
    objects such as numbers, characters, strings, bit-vectors and
    keywords, as well as constant symbols declared by DEFCONSTANT,
    such as NIL, T, and PI. In addition, a list whose car is QUOTE,
    such as (QUOTE FOO), is considered to be constant

The problem comes from  the inclusion of all "self-evaluating objects"
in "simple  constant forms".  

    ...a `simple constant form' will be defined as the union of these
    three items:

    * a self-evaluating object
    * a symbol naming a defined constant (built-in or declared by DEFCONSTANT)
    * a list whose car is the symbol QUOTE

An   array   is  not   only   a   self-evaluating  object   containing
self-evaluating  objects.  it's actually  an object  containing values
(self-evaluating objects), and in such as  way as to be more a list of
variable than  a value but  itself.  That is,  if we don't  classify a
symbol naming  a variable as a  constant, we cannot  classify an array
object containing a lot of  variables as a constant neither.  Just see
the  above  transcript to  see  that  an array  is  a  variable not  a
constant!

Clearly, CLtL gives a logical definition of CONSTANTP, while HyperSpec
does not.  

One  could  say  that the  intent  of  CONSTANTP  (as hinted  by  it's
classification in  HyperSpec under the chapter "3.  The Evaluation and
Compilation", and in the cited issue:

    CONSTANTP is typically used to implement some simple kinds of code
    motion optimizations and side-effects analysis, for example in
    computing the expansion of a macro or compiler-macro. Permitting
    CONSTANTP to return false for the three situations listed would
    inhibit these kinds of optimizations in the obvious situations
    where they were intended to be applied. Permitting CONSTANTP to
    return true in other situations could cause these applications to
    perform semantically invalid "optimizations".

is not  at all to  predicate a constant,  but to have a  predicate for
something  that  can  be  handled  at  compile  (or  macro)  time  for
optimizing.  Well, in that case, it should not be named CONSTANTP, but
perhaps something like "STUFF-THAT-CAN-BE-OPTMIZIED-P".  After all, if
the    standardization     commitee    renamed    SPECIAL-FORM-P    to
SPECIAL-OPERATOR-P, it could as  well rename CONSTANTP to a meaningful
name.

As it is now, CONSTANTP cannot be used for much anything.

Did I miss something?

What is the current status of Common-Lisp standardization?

The most  recent references to X3J13  date back to 1996,  and most are
ten years old...

  Yes.  Standards are prescriptive.  You understand them, you adhere
  to them, /then/ have your own opinions.

| What is the current status of Common-Lisp standardization?

  Published.

| The most recent references to X3J13 date back to 1996, and most are
| ten years old...

  Is it not wonderful?  Nobody has randomly messed with the language
  to fit some misunderstandings or added cruft to fit some marketing
  scheme.  Imagine a programming language that is /not/ a weapon in
  someone else's marketing war, but is stable and has proven useful
  to actual /programmers/ over a whole decade!  Is it not amazing?

--
Erik Naggum, Oslo, Norway

Merry Christmas!

  "Moribundity" appears to be the noun of choice.

--
Erik Naggum, Oslo, Norway

    constant n. 1. a constant form. 2. a constant variable. 3. a
    constant object. 4. a self-evaluating object.

    constant form n. any form for which evaluation always yields the
    same value, that neither affects nor is affected by the
    environment in which it is evaluated (except that it is permitted
    to refer to the names of constant variables defined in the
    environment), and that neither affects nor is affected by the
    state of any object except those objects that are otherwise
    inaccessible parts of objects created by the form itself. ``A car
    form in which the argument is a quote form is a constant form.''

    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.''

    constant variable n. 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.''

    self-evaluating object n. an object that is neither a symbol nor a
    cons. If a self-evaluating object is evaluated, it yields itself
    as its only value. ``Strings are self-evaluating objects.''

Only self-evaluating object could be applied to arrays.
When you evaluate an array, you get the array, ok.
Only that if you evaluate an array twice, you can get a different value.

Just evaluate this if you don't believe me:

(setq a1 (make-array 2 :initial-contents '(:a :b)))
(setq a2 (make-array 2 :initial-contents a1))  ;; a1 evaluated once here
a1                      ;; a1 evaluated twice here, ok, it's same
(equal a1 a2)
(setf (aref a1 0) :x)
a1                      ;; a1 evaluated thrice here, oops, not the same!
(equal a1 a2)

Once again, the point is that an  array is not a value, it's a list of
variables!  And these variables are not constant.

And concerning  the immutability of the specifications,  it just means
that lisp is  supple enough a language to  let it's programmers ignore
awkward  parts of the  specifications and  write their  own "patches",
each and every one of us.

Note that http://www.ncits.org/tc_home/j13.htm
says that:

    J13 - Programming Language LISP

    During 1994, J13 conducted its second public review of X3.226,
    Programming Language LISP, resolved the outstanding TC negative on
    the final ballot, and forwarded the dpANS for final approval.

    The document was approved as an American National Standard on
    December 8, 1994.

    This technical committee is the U.S. TAG to ISO/IEC JTC 1
    SC22/WG16 and provides recommendations on U.S. positions to the
    JTC 1 TAG.

So they've  just approved  a document with  366 unresolved  issues and
_known_ problems.  I'm just pointing  to another problem that does not
seem to be known yet.

I hope this helps.

Pascal

  <http://www.lispworks.com/reference/HyperSpec/Front/X3J13Iss.htm>

I think that ANSI requires that a standard be either revised or re-ratified
at least every 10 years.  So if nothing is done within the next 2 years,
the Common Lisp standard will cease to exist officially.

  How young were when you arrived at the conclusion that you know
  best and that listening to other people is a waste of your time?

| And concerning the immutability of the specifications, it just
| means that lisp is supple enough a language to let it's programmers
| ignore awkward parts of the specifications and write their own
| "patches", each and every one of us.

  While you may believe that you have judged the standard and the
  language and the community of users, you have instead given the
  whole entire world a solid reason to judge you.

  Now that you have demonstrated that you believe that knowledge can
  be acquired without effort, how do you write programs?  With a tap
  of your magic wand, the computer just does what you want, right?

--
Erik Naggum, Oslo, Norway

  Thank you.  Without your valiant effort to teach us all, we would
  not know anything.  Could you hurry up the teaching part, though?
  I am so curious to learn what you look like when you have run out
  of things to tell people and arrive at the point when you listen to
  others.  You see, I am so old that I have seen teenagers who know
  everything and think nobody else could possibly have discovered it
  before they did so many times as to have tired of their kind.

  What is so great about the Common Lisp world is that /everything/
  has been discovered before you.  That is to say, to be truly novel
  in the Common Lisp community, you have to do a lot of /work/.  You
  can learn from people for 20 years and still not have learned it
  all.  This is what computer science was supposed to be like but is
  not because of people like you: people who crave /novelty/ for its
  own sake.  I for one am decidely happy to have been born in a fully
  evolved society so that I did not have to walk miles to get fresh
  water or have to invent my own writing system and everything I value
  in modern society.  It probably sounds strange to you, but I /like/
  not having to discover everything for myself, and so do many other
  Common Lisp programmers.  We do not have to start from scratch, we
  do not /like/ to start from scratch every time, we think it is a
  really great thing that somebody else did so much work before we
  entered the scene that we can do our little part to improve our own
  existence (or that of an employer) instead of having to build an
  entire society from scratch to do it.  And to those who do not want
  to build whole societies merely in order to buy a loaf of bread, the
  freedom comes with a responsibility to learn what went before, to
  show a deep gratitude and respect towards those who /did/ build the
  society where we can buy a loaf of bread for a dollar or two instead
  of having to spend /hours/ to make one ourselves from scratch.

  An even older friend of mine published a book almost 18 years ago,
  with an appendix of self-framed slogans suitable for mounting, one
  of which is applicable to this day.  It reads

      Just because you think you need steel-belted radial tires
       and the store only has polyglas-belted ones at present,
is still no excuse for going off in a corner and reinventing the travois.

  (Michael A. Padlipsky: The Elements of Networking Style and other
  essays and animadversions on the art of intercomputer networking,
  originally ISBN 0-13-268111-0, reissued ISBN 0-595-08879-1.)

  A field does not become a /science/ until those who enter it do so
  with the humility of wanting to learn what prior practitioners had
  done both right and wrong, before they want to practice themselves.
  Computer science is still not a real science because of this.

--
Erik Naggum, Oslo, Norway

Pascal

Even if no major changes are planned, standards committees are supposed to
respond to requests for clarifications, and those should be worked into the
next revision.  I.e. if the standard were a software application, you'd be
putting out bug fixes and point releases.  But you need an active committee
to do that.

Note: I didn't say that the standard was moribund, I said the *committee*
was.  If it's not really dead, it's playing it well.  Was the 5-year
renewal anything more than a rubber stamp?

To be fair, it is possible PB staggered random-accessedly onto the
issues list without first encountering the "this is what we addressed"
intro, the web being what it is.

And his ensuing astonishment that nothing has been done about those for
ten years... aw c'mon, at least he was reading the CLHS! :) So what if
he squeezed off a few rounds based on incomplete understanding. (I think
that is all it was--call me charitable if you like, but you'll be the
first.) Y'all did the same with him. As far as I can make out he came as
a friend, after reading a lot about CL on slashdot or something.

All we had to do is steer him straight, not damn him to the fires
eternal. Plenty of time for that after his next article. :)

--

Worse, in your example you called make-array twice, creating two
different instances of array. constantp has nothing to say about that.

The only problem here, IMHO, is that you are putting your questions in
the form of statements. Slow down and ask. I have been doing C and CL,
for a while, and I myself puzzled over arrays being constantp. I would
not have made your mistake of thinking that mutating an array proved it
was not constant, but I still would not be able explain why arrays
themselves are constantp albeit mutable.

--

Right  now, I'm  scanning HyperSpec  and trying  to  implement missing
COMMON-LISP  functions  on  emacs,  to  allow me  to  use  COMMON-LISP
programs both in clisp and in  emacs.  While I will keep to write LISP
code for  emacs, I'd like  to make it  as COMMON-LISP as  possible and
have as little dependencies on emacs as possible.

So, my interest is half that of an implemented and half that of a user
of COMMON-LISP who needs a precisely defined specifications to be able
to develop portable COMMON-LISP programs.

Now,  concerning CONSTANTP, and  if the  delicate people  reading this
would mind adding a "IMHO" on each line of the following:

The  problem   with  CONSTANTP  comes  from  an   incoherency  in  the
specifications (HyperLisp).

First,  in  section  "2.4.8.12  Sharpsign  A"  it's  explained  how  a
standardized reader  macro can  be used to  build an array,  making an
explicit reference to MAKE-ARRAY.

The signature of MAKE-ARRAY is:

  MAKE-ARRAY dimensions &key element-type initial-element
             initial-contents adjustable fill-pointer displaced-to
             displaced-index-offset

and  you can see  that there  is no  parameter specifying  whether the
array built must be mutable or immutable.

Similarly, section  "2.4.5 Double-Quote" explains how a  STRING can be
read,  with  no  explicit   reference  to  MAKE-STRING,  and  with  no
indication that so-built strings must be immutable or not.

Idem for lists (conses builts automatically when ( a b c d ) is read),
vectors #(...), structures #S(...), not to speak of #. and #P !

More over,  if #. and #P were  not enough, there is  provisions in the
standard to let the user add his own reader macros.

So  we can  have textual  forms  for any  kind of  objets from  simple
integers to  complicated agregate structures, of  which all agregates,
when translated to S-expr must  be detected as immutable by CONSTANTP,
_BUT_ there is no notion of mutable/immutable in COMMON-LISP.

While there is a tentative approach to the immutable concept:

    immutable adj. not subject to change, either because no operator
    is provided which is capable of effecting such change or because
    some constraint exists which prohibits the use of an operator that
    might otherwise be capable of effecting such a change. Except as
    explicitly indicated otherwise, implementations are not required
    to detect attempts to modify immutable objects or cells; the
    consequences of attempting to make such modification are
    undefined. ``Numbers are immutable.''

it is not enough.

Clearly,  it's  lacking  a   (SET-IMMUTABLE  object)  function  and  a
(IMMUTABLEP  object) predicate  to at  least make  a newly  created by
default mutable  object immutable.  These  functions could be  used by
the reader macro functions and by CONSTANTP to correctly implement the
required semantics.

SET-IMMUTABLE would have  to be called on all cons  made by the reader
macro of lists.   (Of course, a specific implementation  of the reader
could optimize  this and have  a (CONS-IMMUTABLE car  cdr) primitive).
This SET-IMMUTABLE function could  then be used by user-defined reader
macros and user functions written in #. to keep the wanted semantics.

<nagging>
While the LISP standardization commitee was sleeping in their coffins,
other languages  evolved and precised  and implemented this  notion of
immutability.  For example, Objective-C,  if only at the class library
level, but with some integration to the language, where @"string", the
readable form of  a literal string object is  explicitely specified to
create an immutable  string instance. And if IIRC,  Java has something
to say about immutability too.
</nagging>

Here is what we get with  clisp, which I'm affraid is according to the
standard unfortunately:

[17]> (constantp #1A( :toto 12 ))
T                                  ;; this is correct

[18]> (setq a (make-array 2 :initial-contents '(:toto 12)))
#(:TOTO 12)
[19]> (constantp a)
T                                  ;; this is not correct!
[20]> (setf (aref a 0) :titi)
:TITI
[21]> a
#(:TITI 12)                        ;; see! A is not constant !
[22]> (constantp a)
T

[37]> (setq a "toto")
"toto"
[38]> (setq b a)
"toto"
[39]> (setf (aref a 1) (code-char 65))
#\A
[40]> (eq a b)
T
[41]> (constantp a)
T                                  ;; What an infamy!!!
[42]> a
"tAto"
[43]> b
"tAto"

Perhaps  users   of  CMU  CL   and  the  happy  users   of  commercial
implementations of COMMON-LISP  could tell us what are  the results of
CONSTANTP in their LISP?

  I did seize the occasion, but you were both unenlightenable and
  unteachable because you had set your mind to the matters about
  which you could be enlightened and taught.

  A student who knows so well what he is to be taught that he rejects
  everything that is not to his liking is a contradiction in terms,
  for it is what you do not know that you need be taught.

  You had the occasion to become enlightened and taught, but remain
  befuddled by your own preconceptions.  Such was your choice, and
  such it shall be.  I wish you better luck in your next life, as the
  one you have wasted so far will require many years to salvage.

  A hint, though: Thinking is not the crime you believe it is.

--
Erik Naggum, Oslo, Norway

I think most things needing doing can be done by layered standards without
destabilizing what is there.  That's just my personal opinion.

In Objective-C, and  with a little common sense,  what you expect from
constant stuff is to be immutable.  A value can be mutable (usually it
is), or immutable thus being like  a constant, only one that have been
created at run-time instead of at compile time (or lexical time if you
will).   In  Objective-C, the  mutability  or  immutability status  is
implemented  specifically by each  class.  There  is a  NSString class
whose instances  are immutable, and a  NSMutableString whose instances
are  mutable.   When  parsing:  @"literal", the  compiler  creates  an
immutable instance (of a subclass  of NSString).  Actually this is the
only place  where the Objective-C  compiler does anything  special vs.
mutability/immutability, the rest is  handled by the class library and
therefore independant  of the language. There are  similar couples for
arrays, dictionaries, etc.

[1]> (constantp #(:a :b))
T

What's shocking me is:

[2]> (constantp (make-array 2 :initial-contents '(:a :b)))
T

This may  be a bug  in the implementation,  but then the  HyperSpec is
somewhat ambiguous,  and I  can see how  a reading  of it can  lead to
implement such a behavior for CONSTANTP.  CLtL does defines informally
a correct and meaningfull CONSTANTP  IMHO, but this formulation is not
used in CLHS.

    - what the language in CLHS means?
      Should (CONSTANTP (MAKE-ARRAY 2 :INITIAL-CONTENTS '(:A :B)))
      return T or NIL?

            T                 |               NIL            | other, N/A
                              |                              |
 Do you call the result of    | Ok, so CLISP got it wrong,   | Please explain?
 (MAKE-ARRAY ...) a constant? | at least you must agree with |
                              | me on that mustn't you?      |
   No         |   Yes         |                              |
              |               | But what about CLHS that     |
How do you    |How do you     | explicitely says that        |
feel that     |explain that   | CONSTANTP should return T    |
CONSTANTP     |one may modify | for array?                   |
returns T for |something that |                              |
something you |you and        | Did they want to mean only   |
don't call a  |CONSTANTP call | for immutable arrays and     |
constant?     | constant?     | boltched and wrote ambiguous |
              |               | "specifications"?            |
What about my |Does it seems  |                              |
suggestion    |illogical to   |     Yes      |     No        |
that the std  |anybody else   |              |               |
comitee       |than me here?  |Then we agree,|Please explain?|
rename that   |               |and since life|To me, this    |
function like |               |is not        |would mean a   |
it did for    |               |agradable with|big            |
SPECIAL-FORM-P|               |ambiguous std,|contradiction. |
      ?       |               |don't you     |WHat did they  |
              |               |agree that we |mean? Why did  |
              |               |should rework |they not write |
              |               |(or add a     |what they      |
              |               |corrective    |meant?         |
              |               |layer on) CL  |               |
              |               |standard ?    |               |
              |               |For example,  |               |
              |               |introducing   |               |
              |               |set-immutable |               |
              |               |and immutablep|               |

I'm not sure *what* CONSTANTP is used for in the wild but I'm willing
to assume, since my experience with Lisp is measured in months and the
spec's age is measured in years, that I may not have grasped the all
the uses of the semantics it does provide. That CONSTANTP takes an
optional environment object argument such as you get with an
&environment variable in a macro lambda list, suggests that it is
perhaps intended for use in writing clever macros that expand into
different things depending on whether various forms they are passed in
can ever change. The following macro is *not* clever but it at least
shows what I mean:

  (defmacro with-no-constants (&body body &environment env)
    `(progn
      ,@(mapcan
         #'(lambda (form)
             (if (constantp form env) nil (list form)))
         body)))

Which gives us:

[7c] FOO(317): (macroexpand-1 '(with-no-constants 10 (foo 10) #1A(:foo)))
(PROGN (FOO 10))
T

Obviously this macro is not much use by itself as any literal code
that might be wrapped in with-no-constants would hopefully be
optimized away by the compiler anyway. But you can, perhaps, imagine
more elaborate uses of this technique.

  "If an implementation chooses to make use of the environment
  information, such actions as expanding macros or performing function
  inlining are permitted to be used, but not required"

  new String("foo").intern() == "foo"

should always be true. But there's no programatic way to determine
that Strings, or instances any other class, happen to be immutable.
Which doesn't seem to matter a lot as there's nothing much you could
do with the information.

Anyway, cheers, and happy spec inspecting.

-Peter