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