>
> 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.

Its a little tricky, since neither remove-key nor remove-value really
describe what *-remove on dictionaries does.  Its more like
remove-mapping.  I'm open to suggestions but off the top of my head
nothing jumps out as great.

> <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.

I agree.

>
> 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.

I'll reread SRFI-1.  I'm not opposed to becoming more precise.

	Scott