Hello,

I haven't thought about this whole email, but I disagree with this part of
your response:

On Thu, Apr 4, 2013 at 8:17 PM, Daniel Hartwig <mandyke@gmail.com> wrote:

> Hash tables are not just a set of (key, value) pairs, they also
> include the particular hash and equality procedures that are used with
> them.  These could be arbitrary procedures, and procedures can not
> generally be converted to a string and back again, so, by extension,
> neither can hash tables even if you could do that for their content.
>

Although hash tables in general do include arbitrary procedures, in Guile's
implementation there are only three to choose from, so it should be
possible to represent them in syntax.

For exactly this reason, I believe that actually "hash table" is a bad name
for the data structure. I think of Guile's hash tables as a generic
dictionary structure with average O(1)-time lookup, insertion and deletion.
It makes sense to me to give this structure an external representation,
because it has a lot of common uses. (It seems especially useful to me for
configuration files.)

That does privilege one sort of generic dictionary structure over other
implementations of the same interface - such as hash tables with different
hash procedures, as you mentioned. This is fine with me, because I think
that use cases fall into two categories. In the common case, the dictionary
will not be in a time- or performance-critical part of a program, and
programmers should use Guile's built-in dictionary types and not waste time
implementing their own. In the rare case, when dictionary lookups are time-
or space-critical and must be optimized, *then* it's worth it to design
custom hash functions and implement hash tables from vectors and similar
things. However, I think that case is sufficiently uncommon that it should
not hold back the common case from having convenient syntax.

Best,
Noah