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 <[email protected]> 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 > > [email protected] > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
