Am Mi., 10. Juni 2020 um 12:16 Uhr schrieb Lassi Kortela <la...@lassi.io>:
Ah, you are right. A `(maybe-assoc key alist)` would be in order. And > `maybe-list-ref`, `maybe-hash-table-ref`, etc. > Yes. But how to organize it best? For those `-ref' procedures that also take a success argument (all of them better should), it's enough to pass `just' for that argument. For the failure argument, it would be nice if Nothing were a thunk that returned itself when called. As it isn't, I think, we need a constant procedure returning Nothing. > IMHO, the RnRS `assoc` procedure sets a precedent that xlist and alist > should be regarded as the same data type. It returns the cdr, which in > an xlist's case is the full list of values for the given key. > I don't get this argument. That `assoc' happens to work on alists with whatever is in the cdr of each association doesn't make alists and xlists the same data type. In fact, as a concrete data type, xlists form a subset of alists, but a proper one. And as an abstract data type, alists form a subset of xlists, but again a proper one. Lisp is kind of funny in that alists came first, and those are more > specialized with support for duplicates and the multiple-value case is > easier to express (the natural `cdr` or a cons is a proper list, and > improper lists are something special). > While many people do not like improper lists, this dislike usually does not include pairs (the same pairs, R7RS is talking about when describing the alist type). Sure, sounds great, and agreed! > Excellent! Arne has expressed an interest in standardizing alist stuff previously > as well, so we should also include him if he wants to join in. > Sure! Arne? > A survey of existing alist procedures would be good preparation. I don't > know of any semi-standard library other than the RnRS, SRFI 1, and SLIB > ones which are minimal. We could do a quick check of the major > implementations' manuals. > And check the existing data types.
