Hello, On Fri, Apr 5, 2013 at 5:35 AM, Daniel Hartwig <mand...@gmail.com> wrote:
> > On 05/04/2013 10:47 AM, "Noah Lavine" <noah.b.lav...@gmail.com> wrote: > > 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. > > > I think you miss the hashx procedures. > Yes, you're right. My mistake. > > 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. > > Where do you get your definition of 'hash table' that the guile type does > not apply? > That was a bad way to put it. I think of the Guile type as defined by an interface, not a particular implementation, so I think "dictionary" is better than "hash table". But it certainly is a hash table on the inside. > > 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. > > That's what the current data type is anyway, and can be used with custom > hash? I'm not sure I follow the distinctions you are making. > I may have explained it poorly last time. I agree that in general, there are many different variants on a hash table, and as you say, they cannot all be written down easily - you can have different hash procedures, different ways to handle collisions, and different policies on when to grow and shrink the table (and maybe more things). However, I think that it's worth having a printed representation for one particular sort of hash table, even though that privileges one sort of hash table over another, because it makes things very convenient in the common case where you don't care about performance enough to customize your hash table. In the performance-critical case, where you are customizing the features of your hash, you can write a custom serializer too. Basically, I think that while it is impossible to serialize all of the things meant by "hash table", it is worthwhile to have a syntax form that means "I want to store these objects in a hash-like dictionary structure, and I don't need to worry too much about performance." I think the gain in convenience is large, and the case where you can't use this is pretty rare. Best, Noah
