On 5/22/11 6:52 AM, Edward Z. Yang wrote:
Excerpts from Milan Straka's message of Sun May 22 06:50:07 -0400 2011:
- 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.
Comment: This would mean you would get no static assurances against mixing up a strict IntMap with a lazy IntMap; for all intents and purposes, this is equivalent to implementing strict versions of all functions on top of a lazy data type.
Not really for *all* intents and purposes. Separating them into different modules makes it very easy to make a top-level decision to import one or the other (or use qualified imports), which is a good deal cleaner than having primes scattered hither and yon. Personally I'm a fan of this approach, because it means we never have to convert between representations but we also clean up the API (as mentioned above). I'm less concerned about the possibility that someone might hand me a map containing thunks. Also, it allows for easily making partially strict IntMaps when you want to be lazy in general but know you must be strict for specific operations. Moreover, if you really want to make the type-level distinction, why not use newtypes? The conversion will be free in one direction, and the other direction can be done by just forcing all the elements in-place (instead of cloning the tree[1]). The only reason to actually duplicate the structure definition is if there's a whole lot of overhead for asking whether elements have already been evaluated. [1] And if you do end up having separate ADTs, then there should be explicit functions for casting from one to the other, so that you don't need to go via (fromAscList . toAscList) -- Live well, ~wren