Date: Mon, 16 May 88 23:51:57 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
I think you've made a useful observation that there a whole slew of potential
(or real) data types in CLtL for which there is no commonly accepted print
syntax, and for which the #S syntax could be naturally extended to cover.
BYTE-SPECIFIER comes to mind, as well as RANDOM-STATE, PATHNAME, HASH-TABLE,
PACKAGE, READTABLE, STREAM, (compiled) FUNCTION, and non-simple ARRAY and
ARRAY with specialized element-type not among {'bit', 'string-char','T'}.
Having a print function presumes having a dynamically distinguishable
type. If BYTE-SPECIFIER is implemented as an integer, you might have
a read syntax for it, but you couldn't expect it to print that way.
(Actually, the Genera 7 PRESENT function allows an optional
type argument for just this purpose.)
On the other hand, I may have to argue against this unifying approach in at
least one or more of the important cases at hand. Lucid, like Symbolics,
already uses the #P"..." approach to pathnames, and probably wouldn't like
to go to a more space-wasting format. And for "database"-like types such
as packages and streams, using something like #S would be a gross over-
simplification; recursive descent throught the slots would indubitably
have incestuous circularities.
Right. You don't want to print an object's implementation. You want
to print something which has a fighting chance of being interpreted
by any Common Lisp, using only CLtL functions.
Incidentally, both you and Touretzky forgot that hash-tables have two
additional interesting properties beyond the :type and :size -- the
:rehash-size and :rehash-threshold. Hash-tables wouldn't be fully
reconstructable from the printed format unless this information were
also included.
-- JonL --
A well-designed #H syntax would be open-ended enough to include all
sorts of info on the hash table. Since a hash table is created by
a call to MAKE-HASH-TABLE, followed by any number of calls to
(SETF GETHASH), the form following the #H should be able to contain
all the arguments of those calls. The format that appeals to
me has one list element per call, each giving the arguments
for that call apart from the table itself:
#H((:test 'eql :size 10) (:blue #(0 0 10)) (:red #(10 0 0)))
Perhaps if the first form is an atom X, it should be taken to mean
(:test X); this supports an earlier proposal as a special case.
Probably if an implementation puts non-standard keywords into the
first list, it should also put in :allow-other-keys t.
There's an obvious generalization here to other "container types",
especially arrays: Their P.R.'s should recapitulate their creation.
By "container type" I mean that the meaning of such an object depends
only on its connections to a set of pre-existing objects, which were
associated with it in the course of its creation. In particular, its
meaning must not depend on objects which refer to it; i.e., there must
be no visible "back pointers". By "meaning" I mean that which is
preserved by the P.R. It's all pretty loose.
-- John