On Wed, Nov 24, 2021 at 2:08 AM Marc Nieper-Wißkirchen <
xxxxxx@gmail.com> wrote:
I decline to impose this requirement on implementations [of dict-ref]
With all due respect, such a decision is unwise. Adding the crucial tail-call guarantee imposes virtually no requirement on implementations as most implementations will already naturally fulfill this requirement.
Please explain why these tail calls are a Good Thing and tail calls in -search are Bad Things.
On the other hand, by not adding the tail-call guarantee, code using SRFI 225 would forever have to live without it (and that means that the applicability of the success/failure idiom would be severely limited).
This strikes me as an exaggeration.
(make-dtd dict-map-id dict-map/srf:125 ...)
one could instead have
(make-dtd dict-map dict-map/srfi:125 ...)
Yes in R7RS. But not in R6RS, where procedures don't have identity, and I want to handle that case as well.
This simplifies SRFI 225 considerably as the extra set of variables ending in `-id` does not have to be exported. It's just superfluous. An efficient implementation of SRFI 225 can use SRFI 229, which was created exactly for such purposes, to store internal values in the tags of the generic procedures like `dict-map`.
At the expense of portability to existing Schemes. I'm not going there.
However, I am not advocating this. As I see it, removing the creation of dictionaries is a mistake; it's needed for some algorithms
If you can create a dictionary from a known DTD, you can create one just as easily using a dictionary-specific constructor. And it's probably the generic function, as opposed to its caller who passes in the DTO, who should decide what kind of dictionary to create. But I am continuing to think about ways and means even if it's not actually necessary.eee
Will possibly be answered in the pure/impure thread.
Yes.
The value of `dtd-mutable?-id` would normally be either (lambda (dtd dict) #t) or (lambda (dtd dict #f)), so that given a DTD and a dictionary one can determine if the dictionary is mutable.
The SRFI doesn't say anything about the variables of the `-id` variables, does it? Besides, what does it have to do with the point raised above?
s/-id//
I don't understand this either. Whereas dict-set returns an updated dictionary, dict-set! mutates the given dictionary. How is that different?
In the earlier SRFIs I referred to, `!` means a linear update procedure where the new value is also returned and the given dictionary may or may not have changed.
Except for SRFI 125, where it means true mutation. (And no, SRFI 125 will not be rejected from this SRFI.)
A DTD does not contain a comparator; it contains a procedure which, when applied to a dictionary, returns its comparator.
`dict-comparator` is ill-defined. What it returns is not a property of an abstract dictionary. It's like defining `(number-color n)`, which is supposed, given an integer `n`, to return its color if it is relevant and `#f` otherwise.
Exactly so. Almost the same is true of dict-ref without a failure argument: it signals an error.
Anyway, comparators do belong to the DTD because procedures like `dict=?` only make sense for dictionaries with the same key comparators. So, logically, dictionaries with the same underlying generic implementation but different types of keys are of a different type. This SRFI does not reflect this yet. (In fact, languages like ML, Haskell, C++, and other modern languages do have different types here, which also helps a lot for error detection.)
Keys don't actually have types, but I think I understand what you mean.