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

> Taylan Ulrich Bayırlı/Kammer scripsit:
>
>> - hash-table-replace!
>
> This was meant to lift -update! over the implicit Maybe monad.  I think
> it's more confusing than worthwhile, though.  Flushed.

Indeed, I also decided against it after all.  Theoretically it fills a
small remaining gap for maximum-performance use-cases so I considered
adding it, but after all I can't imagine any case where I already know
the new value to store into a hashtable, and for some reason now need
the old value.

>> - hash-table-map
>>
>> It was already strange enough without the 'merger'!  I'll clear-copy and
>> for-each if I need anything of this sort.  I usually won't.  The
>> semantics of hash-table-map-values should probably be put into this
>> identifier.
>
> Hmm, but that's not `map` in the domain of hash tables.  I'll think about it.

It indeed doesn't conform to that abstract ideal but I strongly suspect
it makes the language more practical for actual use.  I'm not sure if it
should be added at all though.  Clear-copy & for-each goes a long way.

>> - hash-table-filter/remove!
>>
>> I used a self-defined helper like this 'filter!' in a different
>> programming language for a while (on vectors though), and found myself
>> confusing it with the 'remove!' variant all the time.  Probably because
>> while functional filtering feels like "picking out values," mutative
>> filtering feels like "picking out values (to delete!)" but instead it's
>> "selecting values to keep then deleting the others" which is weird.  I
>> would suggest keeping only remove.  And then there's the problem of
>> confusing remove with delete...  Maybe it should be called "filter-out!"
>> with a rationale slapped on it.
>
> I'll think on this also.  I don't like -out.

I settled with hashtable-prune! after all.  I find it nice enough.

>> - Hash tables as functions
>>
>> Pretty useless.  Just lambda away.
>
> I like them.

Lambda as well as cut (SRFI-26) fulfill the use-case in a perfectly fine
manner, without introducing new operators.

>> - Hash tables as sets
>>
>> Just use actual sets.  (SRFI-113 should drop dependency on SRFI-114 and
>> become a library hosted on Snow and not become standardized other than
>> possibly reaching de-facto standard status.)
>
> In your dreams!

I'll write that library myself then, once we settle on SRFI-126 or an
SRFI-114-less SRFI-125. :-)

>> That's was long and maybe sometimes pretty arrogant, but you know I
>> don't mean to offend. :-)
>
> No problem.

Thanks for being so patient!

Taylan