The main issue seems to be that although the semantics of UIO may be
arbitrary, Wallace's patch actually broke deserialization for any
production-based UArr, and I'm not sure the benefits are worthwhile
(loading a file someone else sent you) given that endianness is
already not taken into account when loading (so the chances of someone
giving you a raw binary file that happens to contain values of the
correct endianness is rather low, it seems).
On a related note, having a (more) complete testsuite might help
prevent patches like this from breaking existing functionality.
Maybe a way to resolve the issue is to use the file size and break it
according to the size of the two halves of the production? This avoids
prefixing array length, but allows the productions to still work.
Either way, I'm in the process of writing a Binary instance, so maybe
we can get the best of both worlds eventually.
Thanks,
Dan
On Fri, Mar 13, 2009 at 7:21 PM, Don Stewart
manlio_perillo:
Don Stewart ha scritto:
[...]
So, the patch is: "just revert this change".
Or... use your own UIO instance. That's why it's a type class!
Why should I rewrite the UIO instance, if one already exists?
Oh, because you want different serialization semantics to the (arbitrary) defaults.
-- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe