FiniteMap: modifyFM

[Jon Fairbairn]

I'm using a FiniteMap with fairly long keys; I need to
change the value associated with a key fairly often. =


The current definition of addToFM looks like this:


addToFM fm key elt =3D addToFM_C (\ old new -> new) fm key elt

addToFM_C combiner EmptyFM key elt =3D unitFM key elt
addToFM_C combiner (Branch key elt size fm_l fm_r) new_key new_elt
  | new_key < key =3D mkBalBranch key =

                                elt =

                                (addToFM_C combiner fm_l new_key new_elt)=

                                fm_r
  | new_key > key =3D mkBalBranch key
                                elt
                                fm_l
                                (addToFM_C combiner fm_r new_key new_elt)=

  | otherwise	  =3D Branch new_key
                           (combiner elt new_elt)
                           size =

                           fm_l =

                           fm_r

(Or at least I wish it did -- the #ifs and lines > 80 chars
make it hard [for me at least] to read).

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


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.

  J=F3n


-- =

J=F3n Fairbairn                                 Jon.Fairbairn@cl.cam.ac.u=
k
31 Chalmers Road                                         jf@cl.cam.ac.uk
Cambridge CB1 3SZ            +44 1223 570179 (after 14:00 only, please!)