Re: Storable instance of () is broken

I don't think it's broken; I think your length calculation is broken.
Instead of asking every use of () to take an extra byte, why don't you just
store a word saying how long your array is?

Alternatively, you could probably avoid special cases with a newtype:

newtype NZS a = NZS { unNZS :: a }

instance Storable a => Storable (NZS a) where
  sizeof
    | sizeof (undefined @a) == 0
    = const 1
    | otherwise = sizeof .# unNZS
  alignment = alignment .# unNZS
  peekElemOff = coerce (peekElemOff @a)
  ....

On Wed, Jan 5, 2022, 3:01 AM Harendra Kumar <[email protected]>
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
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries