Re: [spr4719] Why does #s(foo :bar baz) cause error in ACL?

[smh@franz.com (Steve Haflich)]

[This matter has been assigned the tracking identifier "spr4719".
Please refer to it in any followup communication.]

   Why, in Allegro CL, sharp sign macros for builtin atoms like
   structure, array, etc. cause error?

	   <etlclt:25> (defstruct foo bar)
	   FOO 	
	   <etlclt:26> (make-foo :bar 'baz)
	   #s(FOO :BAR BAZ) 
	   <etlclt:27> #s(FOO :BAR BAZ) 
	   Error: #s(FOO :BAR BAZ) -- invalid form for eval.
	   [1] <etlclt:28> :pop
	   <etlclt:29> (make-array 2)
	   #(NIL NIL) 
	   <etlclt:30> #(nil nil)
	   Error: #(NIL NIL) -- invalid form for eval.
	   [1] <etlclt:31>

This error is unrelated to the `#' reader macros, or even the reader
itself.  The error is being signalled by the interpreter when you try
to evaluate an array or structure.  If you had quoted these forms,
that is,

   '#(nil nil)

instead of

   #(nil nil)

then there would have been no error because the interpreter wouldn't
have been asked to evaluate the array.

The original definition of Common Lisp specified that it was an error
to evaluate any atom that was not a symbol, number, character, string,
and bitstring.  Some implementations signalled error; others treated
these atoms as self evaluating.  X3J13 changed the language definition
in 1988 so that all objects other than symbols and lists are self
evaluating.  You might want to compare CLtL1 pp.54-55 with CLtL2
pp.69-70.

Versions of Allegro before 4.0 conform to CLtL1 semantics; versions
starting wth 4.0 track X3J13 revisions to the language, for which
CLtL2 was a snapshot.