>From: xxxxxx@freenetproject.org
Subject: Re: API conflicts (Was: Re: Reasons for withdrawal)
Date: Wed, 29 Oct 2003 08:19:22 -0600

> Do you mind if I take what you wrote and polish it up for
> inclusion?

Not at all.  However, I might have missed some cases,
so further checks from you or other person will be welcome.

> I don't think we can hope to resolve all naming conflicts

Maybe not.  I guess I can live with them.

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.

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.

--shiro