I honestly think we should make it a Const Int a, instead of a function, so that it's a number in the typeclass dictionary and not a function. On Wed, Dec 13, 2017 at 10:41 PM, M Farkas-Dyck wrote:

On 2017-12-13 08:19 PM, David Feuer wrote:

...

+1, but we should also do this for sizeOf and alignment in Foreign.Storable.

Yes, good idea

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

On 2017-12-13 09:37 PM, Zemyla wrote:

I honestly think we should make it a Const Int a, instead of a function, so that it's a number in the typeclass dictionary and not a function.

I like that idea! On 2017-12-13 09:41 PM, Tikhon Jelvis wrote:

The Const type does not see much direct use in other common Haskell packages. (I only ever encounter it through lens.) So while that might be an elegant design, I think it will make the API more confusing for newcomers.

I doubt whether it's much more confusing than `Proxy`, and would be more efficient in cases where the typeclass dictionary can't be inline. Anyhow, if we began using it in base it would thus gain exposure; it's self-fulfilling either way.

Alternatively, we could have it be `Proxy# a -> Int`, which should have identical performance characteristics to `Const Int a` but with the added benefit that it's a little easier to understand how it's supposed to be used. On Thu, Dec 14, 2017 at 12:37 AM, Zemyla wrote:

I honestly think we should make it a Const Int a, instead of a function, so that it's a number in the typeclass dictionary and not a function.

On Wed, Dec 13, 2017 at 10:41 PM, M Farkas-Dyck wrote:

...

On 2017-12-13 08:19 PM, David Feuer wrote:

...

+1, but we should also do this for sizeOf and alignment in Foreign.Storable.

Yes, good idea

_______________________________________________ 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

-- -Andrew Thaddeus Martin

On Wed, 13 Dec 2017, David Feuer wrote:

+1, but we should also do this for sizeOf and alignment in Foreign.Storable.

If Storable would be intended for tuples, too, and there would be no padding, we could use special Monoids in Const, like so: class Storable a where sizeOf :: Const (Sum Int) a alignment :: Const (LCM Int) a instance (Storable a, Storable b) => Storable (a,b) where sizeOf = liftA2 (,) sizeOf sizeOf alignment = liftA2 (,) alignment alignment Taking alignment into account we could define data SizeAlign = SignAlign {sizeOf_, alignment_ :: Int} instance Monoid SizeAlign where mempty = SizeAlign 0 1 mappend x y = SizeAlign (sizeOf_ x + mod (- sizeOf_ x) (alignment_ y) + sizeOf_ y) (lcm (alignment_ x) (alignment_ y)) class Storable a where sizeAlign :: Const SizeAlign a instance (Storable a, Storable b) => Storable (a,b) where sizealign = liftA2 (,) sizeOf sizeOf However, SizeAlign.mappend this way is not valid because it violates associativity (e.g. sizes 1, 1, 2 with corresponding alignments). Even if it would be valid, it would still differ e.g. from Linux-x86 ABI, since structs are already padded to the next aligned size. At least for the alignments an LCM monoid would work.

On 2017-12-14 05:46 AM, Henning Thielemann wrote:

I still prefer Haskell 98 / 2010.

I agree. I would hesitate to introduce ambiguous types here.