Bit shifting limitations

[David Feuer]

I figured out a way to default arithmetic vs. logical shifts without
introducing a Num dependency: the value of (complement 0) `shiftR` 1 will
reveal the behavior of shiftR, and therefore what shiftRA and shiftRL need
to do.
On Jul 13, 2014 5:35 PM, "John Meacham" <john at repetae.net> wrote:

> On Sun, Jul 13, 2014 at 2:23 PM, David Feuer <david.feuer at gmail.com>
> wrote:
> > Well, bitSize is deprecated in favor of two safe alternatives, including
> > finiteBitSize. It is unfortunate that the signed stuff in my default
> creates
> > a Num dependency--that may be enough to kill it. The case of Integer is
> > pretty peculiar. What do people use that instance for?
>
> Infinite bit sets I guess, I don't think it is that unreasonable to
> exist, were it not for that pesky bitSize.
>
> FiniteBits and that deprecation are GHC specific. Though, it would
> make sense to port to jhc, it's fairly annoying for portable code to
> rely on ad-hoc changes like this.
>
> Looks like some work went into removing the Num superclass in ghc's
> base. Hmm... I think type class aliases are needed to actually make it
> backwards compatible though. Since bit is a primitive, you can get
> zero from the somewhat awkward 'clearBit 0 (bit 0)' and one from 'bit
> 1' and -1 from complement zero so the defaults that were dropped can
> be added back in using those.
>
>     John
> --
> John Meacham - http://notanumber.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140713/e23493a2/attachment.html>