Discussion:
Removing bitSize
David Feuer
2017-07-11 03:50:40 UTC
Permalink
The long-deprecated bitSize method of the Bits class is slated to be
removed in base-4.11 (GHC 8.4). There is one remaining question:
should we replace it with a *function* by that name with a FiniteBits
constraint? I don't feel very strongly either way, but Ryan Scott
seems in favor and Edward Kmett seems opposed. So it seems best to
bring it to the libraries list and let the CLC make the call. If the
function is added, it would look like this:

bitSize :: FiniteBits a => a -> Int
bitSize = finiteBitSize

The biggest downside I see is that we might one day want to reuse the
name for something with a better type, such as

bitSize :: forall proxy a. FiniteBits a => proxy a -> Int
bitSize _ = finiteBitSize (undefined :: a)

or

bitSize :: forall a. FiniteBits a => Tagged a Int
bitSize = Tagged (finiteBitSize (undefined :: a))

or (with type applications)

bitSize :: forall a. FiniteBits a => Int
bitSize = finiteBitSize (undefined :: a)

Thanks,
David Feuer
Ivan Lazar Miljenovic
2017-07-11 04:51:32 UTC
Permalink
Post by David Feuer
The long-deprecated bitSize method of the Bits class is slated to be
should we replace it with a *function* by that name with a FiniteBits
constraint? I don't feel very strongly either way, but Ryan Scott
seems in favor and Edward Kmett seems opposed. So it seems best to
bring it to the libraries list and let the CLC make the call.
As it's already DEPRECATED, I think it should be removed for a release
first (in case anyone is still using it to help drive home the change
in behaviour) before any alternative with that name is added.
--
Ivan Lazar Miljenovic
***@gmail.com
http://IvanMiljenovic.wordpress.com
Henning Thielemann
2017-07-11 13:38:24 UTC
Permalink
Post by David Feuer
The long-deprecated bitSize method of the Bits class is slated to be
should we replace it with a *function* by that name with a FiniteBits
constraint? I don't feel very strongly either way, but Ryan Scott
seems in favor and Edward Kmett seems opposed. So it seems best to
bring it to the libraries list and let the CLC make the call. If the
bitSize :: FiniteBits a => a -> Int
bitSize = finiteBitSize
I'd like to have a solution that allows me to make my code compilable by
many GHC versions. The top-level function with an almost identical
signature seems to fit that requirement best. The solutions using Proxy,
Tagged, and TypeApplication are nice, too, but since there are many
sensible choices there might also be many functions like bitSizeProxy,
bitSizeTagged, bitSizeTypeApp.
David Feuer
2018-02-04 21:15:08 UTC
Permalink
Quite some time has passed since I first raised this question. There
doesn't seem to have been much discussion, but we really need to do
something! Just leaving bitSize as deprecated seems like the worst
option. Does anyone else have anything to add?
Post by David Feuer
The long-deprecated bitSize method of the Bits class is slated to be
should we replace it with a *function* by that name with a FiniteBits
constraint? I don't feel very strongly either way, but Ryan Scott
seems in favor and Edward Kmett seems opposed. So it seems best to
bring it to the libraries list and let the CLC make the call. If the
bitSize :: FiniteBits a => a -> Int
bitSize = finiteBitSize
The biggest downside I see is that we might one day want to reuse the
name for something with a better type, such as
bitSize :: forall proxy a. FiniteBits a => proxy a -> Int
bitSize _ = finiteBitSize (undefined :: a)
or
bitSize :: forall a. FiniteBits a => Tagged a Int
bitSize = Tagged (finiteBitSize (undefined :: a))
or (with type applications)
bitSize :: forall a. FiniteBits a => Int
bitSize = finiteBitSize (undefined :: a)
Thanks,
David Feuer
Andrew Martin
2018-02-04 21:38:36 UTC
Permalink
I'm in favor of removing it entirely. Making it an alias may help people
who want to keep code compatible with base < 4.7, but it could also
introduce some confusion. Some thoughts:

- It doesn't help people who want to write a `Bits` instance for their data
type. That will still require CPP.
- People writing bit-type-polymorphic code will have to upgrade to
FiniteBits when using newer base, which will force CPP for compatibility
anyway.
- People writing bit-type monomorphic code don't even need this function,
since they can just write out the number of bits (except for with Int and
Word, whose sizes vary by platform).
Post by David Feuer
Quite some time has passed since I first raised this question. There
doesn't seem to have been much discussion, but we really need to do
something! Just leaving bitSize as deprecated seems like the worst
option. Does anyone else have anything to add?
Post by David Feuer
The long-deprecated bitSize method of the Bits class is slated to be
should we replace it with a *function* by that name with a FiniteBits
constraint? I don't feel very strongly either way, but Ryan Scott
seems in favor and Edward Kmett seems opposed. So it seems best to
bring it to the libraries list and let the CLC make the call. If the
bitSize :: FiniteBits a => a -> Int
bitSize = finiteBitSize
The biggest downside I see is that we might one day want to reuse the
name for something with a better type, such as
bitSize :: forall proxy a. FiniteBits a => proxy a -> Int
bitSize _ = finiteBitSize (undefined :: a)
or
bitSize :: forall a. FiniteBits a => Tagged a Int
bitSize = Tagged (finiteBitSize (undefined :: a))
or (with type applications)
bitSize :: forall a. FiniteBits a => Int
bitSize = finiteBitSize (undefined :: a)
Thanks,
David Feuer
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
Edward Kmett
2018-02-04 22:41:53 UTC
Permalink
As ugly as it is, this function is still mentioned in the current Haskell 2010 Report, so users should have some reasonable expectation of finding it.

When there is a new Haskell Report that drops it I'd say that is when we should finish its removal.

-Edward



Sent from my iPhone
- It doesn't help people who want to write a `Bits` instance for their data type. That will still require CPP.
- People writing bit-type-polymorphic code will have to upgrade to FiniteBits when using newer base, which will force CPP for compatibility anyway.
- People writing bit-type monomorphic code don't even need this function, since they can just write out the number of bits (except for with Int and Word, whose sizes vary by platform).
Post by David Feuer
Quite some time has passed since I first raised this question. There
doesn't seem to have been much discussion, but we really need to do
something! Just leaving bitSize as deprecated seems like the worst
option. Does anyone else have anything to add?
Post by David Feuer
The long-deprecated bitSize method of the Bits class is slated to be
should we replace it with a *function* by that name with a FiniteBits
constraint? I don't feel very strongly either way, but Ryan Scott
seems in favor and Edward Kmett seems opposed. So it seems best to
bring it to the libraries list and let the CLC make the call. If the
bitSize :: FiniteBits a => a -> Int
bitSize = finiteBitSize
The biggest downside I see is that we might one day want to reuse the
name for something with a better type, such as
bitSize :: forall proxy a. FiniteBits a => proxy a -> Int
bitSize _ = finiteBitSize (undefined :: a)
or
bitSize :: forall a. FiniteBits a => Tagged a Int
bitSize = Tagged (finiteBitSize (undefined :: a))
or (with type applications)
bitSize :: forall a. FiniteBits a => Int
bitSize = finiteBitSize (undefined :: a)
Thanks,
David Feuer
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
--
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.
For more options, visit https://groups.google.com/d/optout.
Loading...