
I'd like to do away with UIO altogether though. pumpkingod:
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
wrote: 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