Email list hosting service & mailing list manager


Re: Changes to SRFI 125 John Cowan 11 Sep 2015 21:18 UTC

Taylan Ulrich Bayırlı/Kammer scripsit:

> - hash-table-tabulate

Flushed.  (Note that my scratch version is at
<http://www.ccil.org/~cowan/temp/srfi-125.html>)

> - hash-table-unfold
>
> I can count you the times I used regular unfold in my (not that long)
> life so far: exactly zero.  I will probably be using hash-table-unfold a
> negative amount of times over time, meaning I can see myself rewriting
> code using it to code that doesn't use it to make it easier to
> understand for mere mortals. :-)

Unfolds are consistently underrated even in the functional programming
community, but their fundamental character as constructors says to me
that they should be provided even if rarely used.

> - hash-table=?

This corresponds to (part of) the Common Lisp function `equalp`, which
is like `equal?` but recursively descends into pairs, arrays, structures
(Scheme records) and hash tables.  If you want me to flush comparators,
I have to keep at least this kind of equality.

> - hash-table-set-entries!

Flushed.

> - hash-table-replace!

This was meant to lift -update! over the implicit Maybe monad.  I think
it's more confusing than worthwhile, though.  Flushed.

> - hash-table-find
> By the way if you make the 'failure' thunk of hash-table-find optional,
> you can stuff the semantics of 'any' into it.  And with some negation it
> can serve as 'every'.  Should be fine for those few use-cases.

I'll consider that.

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

> - hash-table-collect
> Guile and I use *-map->list.

Good one.  Done.

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

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

I like them.

> - 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!

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

No problem.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
He played King Lear as though someone had played the ace.
        --Eugene Field