Storable instance of () is broken

[David Feuer]

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 <godzbanebane at gmail.com> 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 <matthewtpickering at gmail.com> 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 <harendra.kumar at gmail.com> 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 at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries