[Minor] [minor commit] r669 - trunk/include/minor

Jim Blandy jimb at red-bean.com
Tue Oct 24 15:58:37 CDT 2006


On 10/24/06, Karl Fogel <kfogel at red-bean.com> wrote:
> I found the hash iteration interface a bit confusing (though very clearly
> explained).  In the interfaces I'm accustomed to, the 'iterator' object
> is distinct from an individual iteration, in other words it's the same
> object across all iterations.

Right, the iterator object is mutated by each step.  This is a good
point, thanks for raising it.  My motivation for doing it the way I
did --- this is embarrassing --- is that "freeing" the old iterator
and returning a "new" one allows me to implement iterators as simple
integer values, cast to 'mn_hash_iter_t'.  The dream was that the
whole thing could turn into a straight 'for' loop indexing an array.

But it's not worth it.  The 'next' function needs to scan the hash
table for the next non-empty entry, and that requires entering an
incoherent section (at least for now), so there's inevitable function
call overhead there.  The gain is lost in the noise.

> I think the prefix for all Minor hash table functions and types should be
> "mn_hash_" consistently, never "mn_hash_table_".  Or the other way
> around -- just not a mixture of the two, because with the mixture, the
> writer constantly stops to think "Oh, is this one with or without the
> 'table_' bit?"

The thought was that they were operations on a 'hash iterator', not a
'hash table'; the 'mn_hash_iter_' functions were a separate class from
the 'mn_hash_table_' functions.  But it's a 'hash table iterator'
anyway, so this reasoning is  not sound.  I'll change it as you
suggest; it'll tighten up some pretty verbose stuff anyway.

> Also, some systems permit NULL values in hash tables, which allows
> them to be predicate systems without distraction: if the key is there,
> predicate is true, if the key is not there, predicate is false, and NULL
> is the natural value to use when we don't care a whit about the value.

I think in Scheme () or #t would be the natural thing to use in those
cases.  If your C code puts C NULL as a value, what would that look
like to Scheme code?

> Finally, regarding your comment beginning "I'm torn: ...", don't be torn! :-)
> Your decision to make an opaque, type-independent interface from the start
> seems eminently sane to me, anyway.

I'm feeling better about it this morning, too.



More information about the Minor mailing list