[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Procedures (interfaces)

This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.

> Bradd W. Szonye wrote:
>> procedure: *-update * position f [thunk] => *
>> procedure: *-update! * position f [thunk] => unspecified
>> defined for: sequences and ordered collections
>> procedure: *-update-key * key f [thunk] => *
>> procedure: *-update-key! * key f [thunk] => unspecified
>> defined for: sequences and ordered collections

Taylor Campbell wrote:
> I don't understand why you're differentiating between these two, and
> why they aren't defined for dictionaries.

It occurred to me that my suggestion for ordering functions could also
apply here. Instead of two different method names, you could do this:

    procedure: *-update * position f [thunk] => *
    procedure: *-update! * position f [thunk] => unspecified
    defined for: sequences and ordered collections

    procedure: dictionary*-update * key f [thunk] => *
    procedure: dictionary*-update! * key f [thunk] => unspecified
    defined for: dictionaries

    (dictionary* means "dictionary or subtype")

If you're using a collection that is both a dictionary and a sequence
(like an alist), you can use the supertypes to say which behavior you

    (sequence-update c n f) => update the nth pair
    (dictionary-update c key f) => update the value mapped to key
    (alist-update c ? f) => ?

Most likely, the alist implementor will define alist-update with
dictionary semantics rather than sequence semantics. I used different
names for the two interfaces to avoid that ambiguity.

Basically, there are two choices here:
1. More procedure names, no clashes.
2. Fewer names, multiple inheritance clashes.

>> procedure: *-remove[!] * value [thunk] => * value
>> procedure: *-remove-key[!] * key [thunk] => * pair

> Why differentiate between removing and removing keys?

And you could do the same thing here, with roughly the same trade-offs.
If you have a hybrid bag/dictionary, you can use:

    (bag-remove c value) => remove a key-value pair by value
    (dictionary-remove c key) => remove by key
    (bag/dictionary-remove c ?) => ?

Hm, this just helped me resolve the "dictionary question"![*]
Dictionaries should definitely be collections of pairs. If a collection
really needs the "dictionary as bag" concept, you can make it as a
hybrid bag/dictionary like this! Epiphany!

Despite the problem with multiple inheritance name clashes, I think this
kind of polymorphism is probably better than my first attempt. Please
give me a little time to go over the procedure interface again and see
if I can reduce it further using this approach.

By the way, I realize that all of my "help" is probably making a lot
more work for you two. If you need any help with the editing or the
reference implementation, please let me know! (And if you get fed up
with me, well, also let me know, but I hope it doesn't come to that.)

[*] "Is a dictionary a bag with keys or a collection of pairs?"
Bradd W. Szonye