(This is tangential to the srfi discussion, so disregard if you're not interested. In this mail I'm not proposing any change in the srfi.)

On Mon, Jul 3, 2017 at 3:28 AM, John Cowan <xxxxxx@ccil.org> wrote:

Conventional wisdom (e.g. Java) is that making containers thread-safe is a mistake: thread safety is an orthogonal concern and should be managed by a wrapper. Even with the most efficient locks, it's an unnecessary cost most of the time, as even in a multi-threaded system, most containers don't end up being shared.

Actually I agree. I brought up thread safety issue as an example that didn't seem to require describing lots of context, but you're right about it.

My general concern is that, if we imply many APIs to be based on mapping-search semantics, it could be an overspecification.

If you implement the underlying maps ground-up in Scheme, it is trivial to provide mapping-search as a primitive, and then build other APIs on top of it.

However, an implementation may want to take advantage of existing map implementation (e.g. platform-provided native library) or some specialized algorithm (e.g. lock-free binary search tree), and then mapping-search isn't necessarily the most efficient primitive.

It is ok to provide mapping-search, because of it's general interface. What concerns me is an implicit assumption such as "API X can be implemented efficiently, given that mapping-serach is efficient".

I don't think srfi-113 has the same issue, since none of APIs has such assumed dependency on set-search, IIUC. And indeed, its reference implementation searches the underlying table multiple times.

That said, the "earlier-takes-precedence" rule can be achieved efficiently by other means than mapping-search (I just added primitive support of mapping-adjoin feature in Gauche's native tree-map), and since the consistency with alist->mapping is preferable, I support the current precedence rule.