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@evdev.ath.cx>,
> 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
>
>