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

> Taylan Ulrich Bayırlı/Kammer scripsit [on SRFI-126 mailing list]:
>
>> However, you'd need to remove many of the utility procedures with
>> strange semantics,
>
> If you itemize the ones you have objections to, and what is strange
> about their semantics, I'll consider it case-by-case.

OK, but I have to confess that most or all of these are just shoddy
personal opinions.  Note that the (loose) inclusion criteria in SRFI-126
say "must occur frequently in user code," but oftentimes there's the
issue that people don't bother defining a sensible helper when it's a
one-off, and just write more explicit code.  Many times I think that's
actually a good thing because it makes the code more readable, but other
times we might all be missing out on something.

- hash-table-tabulate

In the very rare case I want these semantics for some reason, I'll just
for-each over (iota n).  In the extremely rare case that I also need it
to be highly performant and not allocate the useless iota list, I'll use
'do' or named let.  Since these will be such rare cases, using
hash-table-tabulate would make them less readable; I'll need to look up
its documentation and say "... oh, so it's just for-each over iota."

Maybe there are some types of code-bases where this operation is very
common instead, and I just don't know of it.  Correct me if you know
that to be the case.  This disclaimer applies to most points below as
well and I won't repeat it.

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

Maybe I'm not a True Functional Programmer or something.

- hash-table=?

I can't even begin to imagine use-cases for this.

- hash-table-set-entries!

Don't see needing this; will for-each when I do:

    (for-each (lambda (k v) (hashtable-set! ht k v)) ks vs)

- hash-table-replace!

I'm having a hard time understanding what this does.  Is it a code
obfuscation tool for when you want to do

    (let ((v (hashtable-ref ht k)))
      (hashtable-set! ht k new-v)
      v)

?  I do understand it's more efficient though, so it gets credit for
that.  Maybe worth keeping for situations where you need to punch the
last bit of efficiency out of your program.  I suspect it will be
(ab)used to (unintentionally) obfuscate code most of the time though.

- hash-table-push/pop/inc/dec!  (latter two not added yet)

Meh.  Will clean up some small helper definitions in some code-bases.
Don't really care if they stay I guess.  Simple definitions.

- hash-table-find

*Maybe* this is useful for some things after all (and it can't be
imitated that easily, at least without let-escape-continuation), but

- hash-table-any/every

Nope.

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.

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

- hash-table-collect

This just needs a better name.  "Collect" implies that some values can
be dropped.  It's clearly a form of "map" and should be named as such.

Guile and I use *-map->list.

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

- Hash tables as functions

Pretty useless.  Just lambda away.

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

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

As you see not all are requests for deletion.  In fact I think I'll add
replace!, find, and filter-out! to SRFI-126.  I noticed a potential
third criterion for inclusion of utility procedures, which is roughly
"not necessarily used frequently but very annoying to imitate when
needed."  (And I'll drop the pretense that my spec is minimal in any
way, since the utility procedures in mine has grown quite a bit too now.
Guess I can just add hashtable-map too then, with the semantics of
hash-table-map-values.)

Taylan