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 = addToFM_C (\ old new -> new) fm key elt addToFM_C combiner EmptyFM key elt = unitFM key elt addToFM_C combiner (Branch key elt size fm_l fm_r) new_key new_elt | new_key < key = mkBalBranch key elt (addToFM_C combiner fm_l new_key new_elt) fm_r | new_key > key = mkBalBranch key elt fm_l (addToFM_C combiner fm_r new_key new_elt) | otherwise = 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ón -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk 31 Chalmers Road jf@cl.cam.ac.uk Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!)