[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 1)
- To: Dave.Touretzky@B.GP.CS.CMU.EDU
- Subject: Re: Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 1)
- From: masinter.pa@Xerox.COM
- Date: 7 Oct 88 14:35 PDT
- Cc: firstname.lastname@example.org
- In-reply-to: your message of Sat, 17 Sep 88 06:45:07 EDT
Its almost too late to do anything about it, but I had misfiled the
following message about HASH-TABLE-PRINTED-REPRESENTATION. My only excuse
is that there are 104 pending issues.
If you have or want to make a revision to your proposal, which I will
include, and can get to it *today*, let me know. Otherwise, this will wait
for the next meeting or a letter ballot or something.
Included is a message from JonL about HASH-TABLE-PRINTED-REPRESENTATION and
the last version of it.
Received: from labrea.stanford.edu by Xerox.COM ; 09 JUN 88 21:36:17 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 21:35:32 PDT
Received: from bhopal.lucid.com by edsel id AA18027g; Thu, 9 Jun 88
Received: by bhopal id AA26522g; Thu, 9 Jun 88 21:26:35 PDT
Date: Thu, 9 Jun 88 21:26:35 PDT
From: Jon L White <email@example.com>
Cc: X3J13@sail.stanford.edu, firstname.lastname@example.org
In-Reply-To: Masinter.pa@Xerox.COM's message of 8 Jun 88 20:24 PDT
Subject: Issue: HASH-TABLE-PRINTED-REPRESENTATION
Touretzky actually said he would alter his proposal to account for the
:rehash-size and :rehash-threshold omissions; but this version of the
proposaldoesn't show that. I remember remarking that you still can't
call the objects "first class" if the printed representation cannot be
read in as an equivalent copy; and the fact that CL has some other
that aren't "first class" doesn't argue for doing something substandard
for hash-tables. I don't seem to have a copy of the mail from Dave in
which he said he would alter his proposal.
Date: Mon, 23 May 88 15:37:48 PDT
From: Jon L White <email@example.com>
In-Reply-To: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Mon, 23 May 88
11:27:58 EDT <361.580404478@DST.BOLTZ.CS.CMU.EDU>
re: One problem with the currently proposed #H notation is that it
no way to specify a rehash-size or rehash-threshold. This should not
a fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when
element-type is something more specific than T. The latter problem
also shared by #nA notation.
I think this is a fatal flaw. The fact that *some* complex classes of
arrays also share this fatal flaw is no argument for retaining it. It
is still the case that simple arrays of the more common element types
do not have the flaw; and several years ago there was some discussion
on how to fix other manifestations of the flaw on multi-dimensional
-- JonL --
Edit history: 23-May-88, Version 1 by Touretzky
8-Jun-88, Version 2 by Masinter (as per cl-cleanup discussion)
Hash tables are currently second-class data structures when compared to
lists, vectors, and structures, because they have no READable printed
representation. This proposal introduces a #H reader syntax for hash
tables and a switch to control when hash tables will be printed this way.
Proposal (HASH-TABLES-PRINTED-REPRESENTATION:#H-NOTATION) :
1) Introduce the following reader notation for hash tables:
#nH(type (k1 v1) (k2 v2) ...)
"n" is the size of the table; it is analagous to the :size argument to
MAKE-HASH-TABLE. If omitted, the system picks some reasonable size.
"type" is one of EQ, EQL, or EQUAL. If omitted it defaults to EQL.
The (ki vi) pairs consist of a key and a value. There may be any number
such pairs, including zero. Order is not significant. It is an error
two keys to be identical (using the EQ, EQL, or EQUAL test, as
2) Introduce a switch called *PRINT-HASH* whose initial value is
implementation-dependent. If *PRINT-HASH* is T, hash tables are printed
using the #H syntax (with all optional components supplied), subject to the
usual limits imposed by *PRINT-LEVEL* and *PRINT-LENGTH*. If *PRINT-HASH*
is NIL, hash tables are printed using the current #<HASH-TABLE ...> syntax.
This is a useful upward compatible extension (except in
implementations that have usurped #H for other purposes), with very
low adoption cost.
Cost to Implementors:
A simple change to PRIN1 and the pretty printer. Most of the code
will be similar to existing routines for printing vectors in #()
notation and arrays in #nA() notation. The reader would change to
read this notation.
Cost to Users:
Small. Programs that want to control all *PRINT- parameters will need
to know about yet another parameter.
This proposal makes hash tables first class objects. If
*PRINT-HASH* is T, their contents become visible in all the normal ways,
e.g., if FOO is bound to a hash table object, then typing FOO to a
read-eval-print loop will display the contents of the hash table. Hash
table contents may also be displayed by TRACE if the table is passed as an
argument; they may also be displayed by the debugger. Finally, hash tables
may be appear as literal objects in programs and be read or written to
We know of no current implementations of this proposal.
Although some implementations allow the user to see hash table contents
with DESCRIBE or INSPECT, not all do. CMU Common Lisp's DESCRIBE, for
example, does not show hash table contents. This reinforces the need for
a standard #H notation to guarantee that users can manipulate a hash table
as easily as a vector, array, or structure.
Several alternatives have been suggested for the syntax of #H.
- preferred notation: #H(EQL (FOO 37) (BAR 42))
- dotted pair notation: #H(EQL (FOO . 37) (BAR . 42))
- property list: #H(EQL FOO 37 BAR 42)
- pseudo-structure: #S(HASH-TABLE TYPE EQL SIZE 20 INITIAL-CONTENTS
((FOO 37) (BAR 42)))
One problem with the currently proposed #H notation is that it provides no
way to specify a rehash-size or rehash-threshold. This should not be a
fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is also
shared by #nA notation. Some object that the fact that #A is flawed is no
reason to introduce the same flaw elsewhere.
This prompted yet another proposal:
#[size]H([type] [rehash-size] [rehash-threshold] (ki vi)*)
e.g. #65H(EQL 101 65 (FOO 37) (BAR 42))
along with alternative settings for *PRINT-HASH*, NIL, T, :BRIEF, where the
latter would leave out all of the options.