> > 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@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. 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
Attachment:
pgpW0P0vzgSY2.pgp
Description: PGP signature