Proposal: Value strict versions of containers

Milan Straka fox at
Sun May 22 12:50:07 CEST 2011


> Since there are so many of these functions, I propose we introduce Lazy and
> Strict versions of IntMap.  We should also carefully document operations on the
> IntMap that are strict on all values; for example, filter.  Similar changes
> should be made to Data.Map.


To be more verbose, I would like the following:

- have Data.IntMap.Lazy and Data.IntMap.Strict, with equal set of
  methods (so they can be used interchangeably)

- for backward compatibility, have Data.IntMap as it is, but deprecate
  all strict methods ending with '. In the end, Data.IntMap should just
  reexport Data.IntMap.Lazy.

- the types Data.IntMap.IntMap, Data.IntMap.Lazy.IntMap and
  Data.IntMap.Strict.IntMap should be equal -- so I can use strict
  methods on IntMap someone else created with lazy methods. That is
  simple in absence of type classes.


> There is also a companion proposal: Regardless of whether or not we implement
> Strict and Lazy versions of IntMap, we should implement all of these strict
> versions of functions, because are not easy for end-users to implement.  A
> counter-proposal is, if we split out Strict and Lazy IntMap, we should
> *remove* all strict functions from the lazy map, on grounds that selective
> strictness can be implemented with an extra layer of indirection on the Strict
> IntMap.
> Commentary: I favor separate value strict and value lazy maps, and also believe
> that insertWith' and friends should be deprecated from the lazy versions.  I
> don't think reimplementing all of these functions to be strict is a good idea,
> on code duplication and API clutter reasons.  Remember: at the cost of one
> layer of indirection, you can be selectively lazy using IntMap (Lazy a).
> Discussion period: 3 weeks
> Cheers,
> Edward
> _______________________________________________
> Libraries mailing list
> Libraries at

More information about the Libraries mailing list