Shiro Kawai wrote:
> I'd still like to see a section or a note that refers to names which
> conflicts or confusing with existing srfis and popular
> implementations.  It may be a job of users to look them out ....

Yes, it is, but they shouldn't need to in a well-designed interface that
takes prior art into account. In particular, the large number of
conflicts and points of confusion with R5RS and other SRFIs is not a
good sign for a naming standard.

> ... but having mentioned it in this srfi would be a great help for
> users and implementators.

Which is probably why it's one of the few requirements for a SRFI.

> Something like the following.

[snip long list]

Wow. There are more conflicts than I realized. The conflicts with SRFI-1
and SRFI-13 are especially obnoxious. The author has been challenging us
to name future conflicts, when there are already conflicts with other
SRFIs. That makes it more difficult to combine this with SRFI-1 and
SRFI-13. What's a user supposed to do when he wants both the "generic"
elements of SRFI-44 and the "rich" interface of SRFI-1?

A good naming standard *must* take prior art into account, and it *must*
be careful to avoid conflicts with standard features and libraries.
--
Bradd W. Szonye
http://www.szonye.com/bradd