[Haskell-cafe] RFC: demanding lazy instances of Data.Binary
Don Stewart
dons at galois.com
Mon Nov 19 16:39:05 EST 2007
nicolas.frisby:
> 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:
http://community.haskell.org/admin/account_request.html
and a project:
http://community.haskell.org/admin/
>
> 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