[Haskell-cafe] broken IO support in uvector package, when using non primitive types

[Daniel Peebles]

I have added UAProd-based Binary instances to my copy of the uvector
repo at http://patch-tag.com/publicrepos/pumpkin-uvector . I have some
extensive tests (added to the existing tests directory) of things in
there and they seem to be mostly sane.

The Binary code isn't at all pretty right now, and the UnsafeIO (which
I'm thinking of renaming to UnsafeBinary, thoughts?) that comes with
it is even uglier, but it'll be improving soon. When I clean it up,
I'll submit a patch to the main uvector repo and we can see how it
goes (maybe at that point we can pull out UIO).

Also in that repo are changes that add safety checks to all the
functions I know to be unsafe. Due to the fact that these functions
would previously crash my tests, I'm currently only testing safe
parameter combinations on them, so when I get the tests to check that
errors are being thrown appropriately, I'll also submit a patch for
that.

Cheers,
Dan

On Fri, Mar 13, 2009 at 7:34 PM, Don Stewart <dons at galois.com> wrote:
> 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 <dons at galois.com> 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 at haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>