[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
visible hash tables
- To: MLY@ai.ai.mit.edu
- Subject: visible hash tables
- From: Jon L White <edsel!jonl@labrea.stanford.edu>
- Date: Mon, 16 May 88 23:51:57 PDT
- Cc: Dave.Touretzky@c.cs.cmu.edu, common-lisp@sail.stanford.edu
- In-reply-to: Richard Mlynarik's message of Fri, 13 May 88 09:14 EDT <19880513131438.3.MLY@JACKIE.AI.MIT.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'}.
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.
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 --