[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.)
This suggests that something like the 'purcopy' function is still
needed. However, should this be recursive in the case of hash tables?
Certainly the KEYS of ANY hash table must be thought of as constants,
because otherwise the table can become inconsistent. But I can
think of situations both where the values should also be constants
(if the table is) and where the valueshould not be constants.
Making 'pucopy' non-recursive is fine for large data structures,
like arrays, structures, strings etc., but I think most people
feel that CONSes in list structure should be handled in one fell
swoop. Perhaps a 'pucopy' function should accept a data argument
and an arbitrary number of type specifiers, indicating the
data types to recurse through.
In general I like the idea of quoted constants being read-only,
because it ensures that the semantics of a function at run-time
are apparent from its textual representation as code. If constants
are not read-only then:
(defun foo ()
'(a b c))
(defun foo ()
(setq G00047 '(a b c))
On the other hand, I think it would be consistent to define BACKQUOTE
so that it always makes a fresh copy of its entire argument. This
is reasonable, since BACKQUOTE already has to copy its argument
down to the last comma. Die-hards who really want to avoid the
final CONSing in a BACKQUOTE could use ,'(...) to insert un-copied