Am Do., 22. Juli 2021 um 04:51 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

On Wed, Jul 21, 2021 at 2:24 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

To support keys that are records, one needs even more.

As I noted in an earlier post, we need a dictionary-type-object constructor that accepts an equality predicate (which you can retrieve from a comparator).

What does this mean for alists and SRFI 225?

SRFI 146's mapping type has `mapping-fold/reverse', which is enough to efficiently support it. SRFI 224 can also support this efficiently (through decreasing generators).

However, this strategy will not work for SRFI 167's disk-based key/value stores without loading all the keys into memory. I consider the ability to traverse a dictionary in either direction to be idiosyncratic; if you want the ability, you can write a dictionary type object with suitable procedures.

The origin of this issue was not to provide traversal in each direction for all kinds of dictionaries but to understand that one may want to be able to view the same underlying Scheme type as different types of dictionaries. We have seen the issue with alists/plists, and the same issue shows up with, say, an ordered SRFI 146 mapping that we want to consider as an ordered dictionary in the reverse direction. It's just another example that the Scheme type predicates are too coarse to use as a dispatch mechanism.

SRFI 225 in its current shape, however, has to draw a line where there should be none. As it needs at least one argument of dictionary type, it cannot support constructors like Z or (lambda () '()). C++'s overloading mechanism has the very same problem. For example, it can support binary `+' but not nullary `+'. But there is no need to repeat this mistake.

I understand what nullary constructors are, but not why they are relevant to SRFI 225, which provides no generic constructors of any kind, the assumption being that the information required by a constructor is arbitrarily different for different dictionary types.

The latter is an artificial problem due to the current approach of SRFI 225 because predicates like `mapping?' or `hashtable?' are far too coarse. If on the other side, dictionary-type descriptors are used, this missing piece of information can be easily put into them.

One note about predicates being too coarse in general: Of course, one could try and write a predicate, say, `eq-hashtable?' and register a dictionary type with it. This will work as long as no other part of the program (or the implementation itself) registers a dictionary type with `hashtable?'. That programs using SRFI 225 are generally not composable is a severe design error with the current approach, but this only becomes even more severe when lots of fine-grained predicates are used? (Another issue with this is that the fine-grained predicates may take more time to execute than just a simple `hashtable?'.)