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.
From: scgmille@xxxxxxxxxxxxxxxxxx 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@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. 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