FiniteMap: modifyFM

[Simon Marlow]

> 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.
>=20
> 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?=20

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?
>=20
> so addToFM_C would become modifyFM
>    addListToFM_C ----"--- listModifyFM
>=20
> 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