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