John Cowan <xxxxxx@mercury.ccil.org> writes:

> Taylan Ulrich Bayırlı/Kammer scripsit:
>
>> It makes "logical" sense to return the keys and values from
>> hash-table-keys and hash-table-values as sets and bags respectively,
>> since they have no order.
>
> It would be logical.  But, erm, the sample implementation of SRFI 113
> presumes hash tables.  So ....

Oh, hahaha, I didn't think of that.

>> Or maybe you don't want to intermingle your APIs *that* much (keep
>> dependency limited to SRFI-114)
>
> (grabs any excuse for cover) ... Sure.

Lists are fine, really. :-)

In my API I decided to support key/value/entry lists (the last
effectively hashtable->alist) after all, in addition to the
vector-returning variants from R6RS, because I imagine you really want
to filter, partition, find, or do other listy things on the results some
times, for which vectors aren't nice at all.  It feels like a wart, but
that's what I get for remaining backwards compatible with R6RS (although
I also still think there might be worth in returning vectors instead of
lists for efficiency reasons).

Taylan