Re: cannot compile: srfi-10 define-reader-ctor 'hash '#,(

[Mark H Weaver]

Jan Nieuwenhuizen <address@hidden> writes:
> I mean an standardized, ascii/utf-8 non-opaque (#<hash table xyz>)
> representation of hash tables, something like
>
>     #,(hash (key0 value0) .. (keyn valuen))
>
> that upon `read', produces a hash table.

This has been proposed several times before, and although it generally
sounds like a nice idea, there are unfortunately several complications:

1. There are at least three different kinds of hash tables in Guile:
   native legacy Guile hash tables, SRFI-69 hash tables, and R6RS hash
   tables.

2. For each of these three kinds of hash tables, they are further
   divided into multiple flavors depending on the equality predicate and
   associated hash function: eq?, eqv?, equal?, and potentially other
   kinds defined by the user.

3. If the equality predicate is eq? or eqv?, then there's no way to
   write a hash table and then read it back in without losing
   information.  For both of these kinds of hash tables, mutable objects
   that produce the same output can either be the same object or
   different objects.

4. Unlike SRFI-69 and R6RS hash tables, native legacy Guile hash tables
   do not keep a record of which equality predicate is used to store
   their elements.  Instead, it is the user's responsibility to use the
   correct accessors (hash-ref, hashq-ref, hashv-ref, hashx-ref)
   mutators, and other procedures.  It is even possible to use both
   hashq-set! and hashv-set! on the same hash table, although it's
   almost certainly a bad idea to do so.  This means that when asked to
   print a native hash table, Guile doesn't have the needed information
   to print what equality predicate the hash table uses.

I should also mention that it would not be enough to allow 'read' to
read hash tables.  To compile a source file containing literal hash
tables, we'd also need to add support to our assembler and loader to
serialize hash tables to .go files and load them back in.

Regarding complication #1, at some point I'd like to at least merge
SRFI-69 and R6RS hash tables into the same underlying data type.  How to
merge those with native Guile hash tables is not obvious because of
complication #4.  One idea is to record the equality predicate in the
hash table, but allow the predicate to be "not yet determined" when a
hash table is created by 'make-hash-table' before its first element is
added.

If that problem was solved, then complication #2 could be handled by
annotating the external representation with the equality predicate.

I see no good solution to complication #3, but I suppose we could
document that information can be lost.

      Mark