replies to hash table comments

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri 13 May 88 23:33:21-EDT
    From: Dave.Touretzky@C.CS.CMU.EDU

    To Moon:  there are three reasons why DESCRIBE doesn't solve the problems
    that arise in teaching beginners about hash tables:

      1. In some implementations, DESCRIBE does not show the contents of a
	 hash table.  CMU Common Lisp currently displays this regrettable (but
	 legal) behavior.

I think it would be better to fix the regrettable implementations than
to assume that they will always stay that way and therefore we have to
change the language to work around their flaws.  If we're going to
change the language, I think it would be better to change the language
to be more specific about what DESCRIBE is for than to introduce new
substitutes for DESCRIBE on the assumption that we can never change
DESCRIBE.

      2. It is a hassle for a beginner to have to type (describe my-table)
	 every time he wants to see what's inside his hash table.  

Then he should get a better programming environment that allows this
command to be executed with less hand motion.  Several exist.

								   And if
	 he's passing the hash table as an argument to a function, it would
	 be nice if its contents could be displayed automatically by TRACE
	 or by the debugger simply by setting *PRINT-HASH* to T.

Now this is an argument that I find more convincing.  On the other hand,
I hate environments where TRACE dumps out such large arguments that I can't
see what's going on.  I suspect your proposal can only fly if there is a
length limit and a level limit on printing of hash table contents.  Of course
what's really needed is a better TRACE that shows only one line worth
of information to start, but saves the data and provides a convenient
interface for getting more detailed information when it is wanted.  Hasn't
it been more than ten years since the first time I read a paper describing
something like that?  It's been so long, I forget.  Most Lisp implementors,
Symbolics' included, don't seem to have much imagination.

         This kind
	 of behavior would make hash tables a first class "visible" data
	 structure, as easy to understand as lists and vectors.

Surely not, since hash tables have inherently more complicated structure.

      3. The proposed #H notation would make it possible to read and write
	 hash tables from files, and to create them interactively with a single
	 expression rather than doing a MAKE-HASH-TABLE and a bunch of SETF's.

I don't find this convincing.  #H wouldn't change what is possible in either
the file case or the interactive case, it would just make it syntactically
simpler.

Here's my problem: This is a slippery slope: today it's hash tables,
tomorrow it will be random-states, next week it will be CLOS objects,
where will it end?  Also bear in mind that I hate the #A and #S syntaxes
and disable them for output whenever I can.  I just don't like seeing
huge amounts of output shoved in my face.  That leaves me predisposed to
oppose proposals like this one.