Am Do., 18. Nov. 2021 um 23:18 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

On Thu, Nov 18, 2021 at 5:30 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

In what follows, I will call the functional update versions of procedures "pure", and the corresponding procedures ending in "!", I will call them "mutating".

I agree with the use of "pure', with the extension that if there are no update operations at all, the type counts as pure. However, I think it is better to use "impure" as the complementary term. I have now specified that if an instance of an impure dictionary type is in fact immutable, it still counts as impure for this purpose. I have for these reason replaced `dict-mutable?` with `dict-pure?`.

Then it is really a per-dtd property and not a per-dict property; thus it should be a property of a dtd and not a property of a dictionary. Everything else is confusing and not meaningful.

The current draft of SRFI 225 proposes that a dictionary type either supports the pure set or the mutating set. This makes writing a generic algorithm that does non-trivial things inconvenient. If it shall be usable for all dictionary types, it will likely have to come in a pure version and in a mutating version, so it basically has to be written twice.

Which in my view is even more inconvenient both to use and to implement.

I don't understand what your reply has to do with what I wrote.

One can take this as a sign that SRFI 225's DTDs confound two different entities (pure and imperative dictionary types) that are basically disjoint.

Most operations do not involve update and are the same for both types.

It's not the number of procedures exported by the API that count; it's about what sets of procedures have to be used when implementing common algorithms involving dictionaries.

But one can also take this as a hint that SRFI 225 should be amended to make generic code really generic over both functional and imperative dictionary types. One way to achieve this is to reactivate the linear update procedures à la SRFI 1 that have been dropped in some form. Linear update procedures can be uniformly defined for functional and for imperative dictionary types so writing generic code will again be possible without duplication. One probably then also wants to have some way to copy a dictionary to be able to turn imperative algorithms into pure ones.

The further I went down that path, the more complexities and difficulties arose.

Can you explain what you found complex or difficult?

Indeed, I am seriously considering reducing the scope of SRFI 225 further by getting rid of all the update procedures entirely (in which case dict-ref would become primitive).

That would reduce the applicability of SRFI 225 substantially.

I am reluctant to perform this featurectomy, and I think the present compromise serves most use cases.

It serves the use cases where updates are not needed well.  It doesn't for generic code that needs to make updates.