Re: Storable instance of () is broken

It is a bit peculiar that that would be so. Maybe there's some efficiency reason, but it doesn't seem very strongly motivated. On Wed, Jan 5, 2022 at 5:40 AM Georgi Lyubenov wrote:

I have an additional question:

It is true that in a strict/unboxed language, the type of () is sufficient to reproduce its value. However, here, trying to store undefined :: () is no different from trying to store () :: (). Is this difference in behaviour with other instances of Storable (where presumably trying to store undefined will blow up, as there is indeed some work to do there) intentionally ignored?

On Wed, Jan 5, 2022 at 12:26 PM Matthew Pickering wrote:

...

I agree with the other replies to this thread, I just reply to point out the Binary instance for () is the same.

On Wed, Jan 5, 2022 at 8:01 AM Harendra Kumar wrote:

...

The Storable instance of () is defined in the "Foreign.Storable" module of the "base" package as follows:

instance Storable () where sizeOf _ = 0 alignment _ = 1 peek _ = return () poke _ _ = return ()

The size of () is defined as 0. It sounds absurd for a Storable to have a size of 0? This means that we can read an infinite number of () type values out of nothing (no memory location required) or store an infinite number of () type values without even requiring a memory location to write to.

This is causing a practical problem in our Storable array implementation. The array is constrained to a Storable type. Since () has a Storable instance, one can store () in the Storable array. But it causes a problem because we determine the array element size using sizeOf on the type. For () type it turns out to be 0. Essentially, the array of () would always be of size 0. Now, we cannot determine the length of the array from its byte length as you could store infinite such elements in an empty array. The Storable instance of () seems to be an oddity and makes us use a special case everywhere in the code to handle this, and this special casing makes it highly prone to errors when we change code.

Can this be fixed? Is there a compelling argument to keep it like this? A possible fix could be to represent it by a single byte in memory which can be discarded when reading or writing. Another alternative is to not provide a Storable instance for it at all. Let the users write their own if they need it.

If you think this does not have a problem, can you suggest how to elegantly handle the array implementation problem as I described above?

Thanks, Harendra _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries