Backquote Constants

[ELIOT@cs.umass.edu]

>From:	IN%"sandra@cs.utah.EDU"  "Sandra J Loosemore" 12-JUN-1988 02:41
>
>> From: edsel!jonl@labrea.stanford.edu (Jon L White)
>> 
>> re:     What about constant hash-tables?  No variety of QUOTE can build
>>         a constant hash table because there is no notation for them.
>>         (I don't count #.(make-hash-table...) because it's so gross.)
>> 
>> There is a proposal before X3J13 now (presented by Dave Touretzky) to
>> give a printable representation to hashtables.  If a sufficiently powerful 
>> version of it is adopted, then it should be possible to use QUOTE to 
>> reference a constant hashtable.
>
>There is already a way to make a constant hashtable with QUOTE.  Try:
>
>    (defmacro make-a-constant-hash-table ()
>        `(quote ,(make-hash-table ...)))
>
>This same trick can also be used to make "constants" out of other kinds
>of weird objects, like packages or streams.
>
>-Sandra
>-------

At first I thought this was crazy, since this implies that backquote
copies data inside a comma and I didn't think backquote was allowed
to do this.  However, Cltl P.350 says:
"...an implementation is free to interpret a backquoted form as any form
that,... is EQUAL to the result implied by the above definition."
(My caps.)

So, you are right, and CltL is (in my opinion) wrong.  As CltL says
on page 351  "There is no good reason why copy-list should be
performed, but it is not prohibited."  If there is
no good reason why copying should be performed, then it *should* be
prohibited.  I don't know of any implementation which gratuitously
copies extra structure in backquoted forms and I consider the
possibility to be grossly unintuitive.  In fact, I think some code
I wrote a few years ago is probably "in error" because of this
very obscure ambiguity.  I strongly believe that the intuitive way
for backquote to work is to directly incorporate the results
of comma evaluation into the result without modification,
exactly as if the corresponding set of calls to CONS had been
coded directly.  Unless there is a good reason for the ambiguity in
the definition it must be considered a bad definition.

Perhaps the ambiguity in the definition is an attempt to allow
for some of the read-only/collapsing optimizations that are being
discussed.  If so, then as KMP said this is an attempt to combine
two kinds of functionality into a single construct.  I consider
backquote to be a *shorthand* data construction primitive.  Anything
produced by backquote can, more generally, be produced by a combination
of CONS, VECTOR, QUOTE and other functions.  

If we need a way to construct read-only data structure (it would be
nice) then there should be a *general* way to do so, corresponding to
the general use of CONS, VECTOR and QUOTE to produce data structures.
It would be unfortunate to introduce a new way to manipulate data
without making it general. 


As an aside, the description of the difference between ,@ and ,.
seems to be incoherent.  The syntax ,. indicates that it is
permissible to destroy (i.e. incorporate?) the list produced
by the following form.  However, the example on p.351 indicates
that it is permissible to incorporate the list produced by the ,@ form
also.  I fail to see how these differ.