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 <mand...@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
