On 2021-05-28 23:47 -1000, Shiro Kawai wrote:
> The '/key' suffix is consistent within srfi-224, but I'm worried that
> srfi-146 (scheme mapping) has mapping-find and hashmap-find, in which the
> predicate takes a key and a value.
> For inter-srfi consistency, we'd expect imapping-find takes a predicate
> with two arguments.
> Would it bother too much if *-find deviates from '/key' suffix rule?

Unfortunately, this incompatibility between 224 and 146 extends beyond
just (i)mapping-find.  Here are some other procedures from 146 which
are analogous to the /key versions of 224:

* mapping-count
* mapping-any?
* mapping-every?
* mapping-filter
* mapping-remove
* mapping-map
* mapping-fold
* mapping-map->list
* mapping-partition
* mapping-update (CPS procedure; 224's version uses Maybe)

I believe that the only way to resolve this would be to eliminate
the "without key" variants from SRFI 224 and to make passing the
key the default behavior for all of these procedures.  I can see
arguments for and against such a major change; what do you think?

The most egregious incompatibility occurs with the `map' procedures;
SRFI 146's mapping-map transforms both the values and keys of a
mapping.  I've added imapping-relation-map to provide this behavior,
which is, I think, unique among map functions on dictionary types.

> By the way, here's my survey on the find/any/any? operations in various
> srfis:
> https://practical-scheme.net/wiliki/schemexref.cgi?Concept%3AFindAndAnyInCollection

Thanks!

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"[Continuous functions] turn approximation into precision and
open the doors of calculus to reality." --Henle & Kleinberg