HASH-TABLE-PRINTED-PREPRESENTATIONHash 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.
#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 of such pairs, including zero. Order is not significant. It is an error for two keys to be identical (using the EQ, EQL, or EQUAL test, as appropriate.)
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.
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.*PRINT- parameters will need to know about yet another parameter.*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 files.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.
- 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.
- - - - Additional Comments - - - - - 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 datatypes that aren't "first class" doesn't argue for doing something substandard for hash-tables.
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.
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 arrays.
TITAN TITAN D"â"#f !<9¡n ôlBzº*start* 01240 00024 USf Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU> Redistributed: xerox-cl-cleanup^.pa Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 13 OCT 88 14:37:25 PDT Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88 14:27:50 PDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA21150; Thu, 13 Oct 88 15:26:02 MDT Received: by defun.utah.edu (5.54/utah-2.0-leaf) id AA19904; Thu, 13 Oct 88 15:26:00 MDT From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8810132126.AA19904@defun.utah.edu> Date: Thu, 13 Oct 88 15:25:59 MDT Subject: issue HASH-TABLE-PRINTED-REPRESENTATION To: cl-cleanup@sail.stanford.edu
I want to second the comments that have already been made at the meeting, to the effect that the variable should be called *PRINT-HASH-TABLE* and that there should be a corresponding :HASH-TABLE argument to WRITE.
I like the syntax suggested in what is described as "yet another proposal" but the way it specifies the optional parts is broken. It should be
#[size]H([type [rehash-size [rehash-threshold]]] (ki vi)*)
Finally, I agree that array printing is also broken and that it would be a mistake to propagate the same problems to other types.
-Sandra -------