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.
On Wednesday, Oct 29, 2003, at 17:25 US/Eastern, Shiro Kawai wrote:
Personally I strongly wish the remove/delete issue would be solved by renaming them to something more descriptive. (e.g. remove-key, remove-value, etc.) Among various Scheme implementations, we have several pairs of words which are used arbitrarily --- create/make, ref/get, set/put, etc. It is a lot of annoyance when you use several implementations. Remove/delete is another pair, but srfi-1, 13 and 14 have set a consistent usage. I wish other srfi would follow it. Certainly, as Taylor mentioned in <6F15F131-0A58-11D8-8E6E-000A95CCCEE4@xxxxxxxxxxxx>, their name themselves don't conflict to each other. However, I think one point of this srfi is to give a consistent naming so that people can use large number of similar APIs easily---in this respect, it is worth to extend that scope to other srfis, so that people using multiple srfis get benefit of consistent naming.
You make a good point. How about this:
*-DELETE[-whatever] deletes individual values.
*-DELETE-AT deletes values at given indices.
(*-remove PRED? COLLECTION) does like SRFI 1 does.
And also this brings me to another point: argument order (yes, I know
this has been mentioned before, but I don't remember what the response
was, if there was any). I have most often seen, and always followed,
this convention:
Datastructure operations take the datastructure as the _first_
argument. Those that operate on multiple datastructures are usually
higher-order operations anyways, and so a different rule applies to
them. There are a couple of exceptions, e.g. {VECTOR,STRING}-COPY!,
but that's the only one I can think of off of the top of my head.
Examples of these: TAKE, DROP, *-REF, *-SET!, *-GET, et cetera
Higher-order datastructure operations whose function argument is
optional follow the same convention.
Examples of these: DELETE, DELETE-DUPLICATES, et cetera
Failure continuation arguments are _last_, without any exception that
I can think of.
Higher-order datastructure operations whose function argument is _not_
optional take the function _first_.
Examples of these: MAP, FOR-EACH, FOLD, [the same operations on
strings and vectors from SRFIs 13 and 43], FILTER, et cetera.
There are some disagreements with this in SRFI 44: the fold
operations and the dictionary updating operation are the two most
notable ones I can think of. Presumably these are due to the fact
that many dispatching systems work only on the first argument, but
that doesn't change the fact that it breaks these argument order
conventions...
And now I'm worried about the silent incompatibility of list=, regarding how elt= is called. srfi-1 specifies it precisely, but srfi-44 is vague about it. It may lead to a situation that two funcitons, same name and same signature, almost always works identically except maybe some rare cases. I think srfi-1 made an effort to specify it in such a precision that there's little room of unpredictable behavior. This srfi can follow it, I guess.
Yes, I agree with this: it would be good to specify that #T is automatically returned for 0 and 1 collection arguments; on two collections, ELT= is applied to consecutive elements of each; and on more than two collections, *= is folded across the collections.
--shiro