argument order of functions in Data.Bits
The version of Data.Bits which is shipped with GHC-6.2 is marked as experimental. So changes in the API are still possible? :-] My experiments suggest that the functions should have a different order of arguments. Many of the functions of this module alter some bits in a machine word, thus they can be considered as update functions and their type signature should end with a -> a. Then we could easily combine several operations this way shiftL 2 . clearBit 7 . setBit 4 . setBit 1 instead of flip shiftL 2 . flip clearBit 7 . flip setBit 4 . flip setBit 1 or (`shiftL` 2) . (`clearBit` 7) . (`setBit` 4) . (`setBit` 1) . I don't see the benefit of urging the programmer to use infix notation instead of prefix notation here, e.g. (w `shift` 2) instead of (shift 2 w).
On Thu, Apr 07, 2005 at 08:54:09AM +0200, Henning Thielemann wrote:
The version of Data.Bits which is shipped with GHC-6.2 is marked as experimental. So changes in the API are still possible? :-]
My experiments suggest that the functions should have a different order of arguments. Many of the functions of this module alter some bits in a machine word, thus they can be considered as update functions and their type signature should end with a -> a. Then we could easily combine several operations this way
shiftL 2 . clearBit 7 . setBit 4 . setBit 1
instead of flip shiftL 2 . flip clearBit 7 . flip setBit 4 . flip setBit 1
or (`shiftL` 2) . (`clearBit` 7) . (`setBit` 4) . (`setBit` 1) .
I don't see the benefit of urging the programmer to use infix notation instead of prefix notation here, e.g. (w `shift` 2) instead of (shift 2 w).
Ah, This has bothered me too. I vote for the change... John -- John Meacham - ⑆repetae.net⑆john⑈
participants (2)
-
Henning Thielemann -
John Meacham