Proposal: Value strict versions of containers

wren ng thornton wren at freegeek.org
Mon May 23 11:22:02 CEST 2011


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



More information about the Libraries mailing list