[Haskell-cafe] RFC: demanding lazy instances of Data.Binary

Don Stewart dons at galois.com
Mon Nov 19 16:39:05 EST 2007

>    I've got a first draft with the newtype and just an instance for list.
>    If you'd prefer fewer questions, please let me know ;)
>    0) I've cabalised it ("lazy-binary"), but I don't have anywhere to host
>    it. Would it be appropriate to host on [1]darcs.haskell.org or HackageDB
>    (yet?). Suggestions?

You can host it on code.haskell.org, ask for an account here:


and a project:


>    1) The fact that serialisation is fully strict for 32760 bytes but not for
>    32761 makes the direct application of strictCheck intractable. Do you have
>    any ideas how to circumvent that?
>      ((unLazy . decode . encode . Lazy) `asTypeOf` id) (take 32760 (repeat
>    ()) ++ undefined)
>            => undefined
>      ((unLazy . decode . encode . Lazy) `asTypeOf` id) (take 32761 (repeat
>    ()) ++ undefined)
>           => lots of ()s and then undefined

What's happening here?

>    2) Also, any suggestions for other datatypes to provide default instances
>    for? Tree type structures immediately raise the question of which
>    traversal should be the default. I'm learning towards providing none since
>    the goal of constant space usage actually depends on the serialisation
>    order matching how the deserialised tree will be traversed.

Lazy Arrays?
>    3) I don't think it is applicable in anyway whatsoever to strict types
>    like Int, Data.Set, and Data.Sequence? Counter-arguments?

Well, atomic types like Int, I don't think it makes sense, but Sets and
Sequence are lazy, aren't they?

>    4) Perhaps the tight correspondence between serialisation and traversal
>    necessary for constant space usage does indeed mean that the instance for
>    the lazy list is the only appropriate one to provide. Perhaps the Chunks
>    data type and a function splitN :: Int -> [a] -> Chunks [a] would also be
>    helpful.

Yes, it is probably the only lazy instance anyone cares about, anyway.


-- Don

More information about the Haskell-Cafe mailing list