Now, in the case where equality from Ord key is an equivalence rather than true equality, I can see that using "new_key" in the otherwise case is the right thing to do.
For my case, it means that the recently allocated new_key replaces the old key that will have been around longer. Doesn't this interact badly with generational collectors?
Is this causing you real grief? If it is, as you say, the Right Thing To Do, then can we really change it?
Oh yes, and since the similar operations on Refs and states are called modifyBlah, shouldn't the _C versions of operations on FiniteMaps be called something with "modify" in them?
so addToFM_C would become modifyFM addListToFM_C ----"--- listModifyFM
etc. I think names with words rather than abbreviations are easier to read when returning to something after a long period of absence.
I agree, and if I had my way we would remove all the 'FM' suffices too. But name changes shouldn't be made gratuitously; FiniteMap is one of the more heavily-used modules in the libraries (certainly by me, and I expect other people too). I suppose we could rename everything exported by the library, leaving the old names in place for a couple of versions (deprecated, of course). Would someone like to suggest a complete new interface? Cheers, Simon