[Haskell-cafe] strange stack overflow with Data.Map
Christian Maeder
maeder at tzi.de
Fri Dec 30 05:33:30 EST 2005
Jean-Philippe Bernardy wrote:
>> insertWithKey f k x = insertWith (f k) k x
>
> This is the case if the key type has structural equality. Otherwise,
> the key passed to the combining function, which comes from the map,
> can have a different value. Not that I support this style of coding,
I don't think, that we need to consider old and new keys (different but
yielding EQ).
> It's a change to consider. We might want to deprecate the withKey
> variants (and implicitly the non-structural-equalilty types for keys).
At least {fold,map,filter,partition}WithKey functions are (I think) more
useful than {insert,adjust,update}WithKey, so there will be no general
rule for withKey-variants.
(I've never used {union,difference,intersection]WithKey, how important
are these?)
I would not impose an implicit requirement for strong structural
equality/order on the keys. But it would suffice to document which of
two "equal" keys is dropped or kept. Maybe it is even possible to keep
"Set a" somehow in sync with "Map a ()" or an identity "Map a a".
(And "Set (MapEntryPair a b)" to "Map a b")
On the other hand, if we would forget about biasing also for sets than
insertion could be optimized to do nothing with sets that contain
already the element. (Maybe that should even be changed so in Data.Set
for efficiency reasons. An extra function might do the job of actually
replacing an equal element.)
Christian
P.S. left-biasing for Set.intersection still needs to be checked in
(I've sent a patch some time ago)
More information about the Libraries
mailing list