I don't have a particular implementation in mind but as a general idea it would make the treatment of Integers the same as the treatment of the standard-size bounded ints. A possible implementation might be a stream cipher that uses 128-bit Integers instead of 32-bit ints (bitwise rotations have been used in more than a few stream ciphers). For arithmetic purposes, rotation is also useful for implementing multiplication of finite fields. -Pete On Sep 19, 2006, at 3:03 AM, Lennart Augustsson wrote:

And what would rotating an Integer mean? The only sensible interpretation I can think of is to make it behave like shift.

On Sep 18, 2006, at 23:46 , Peter Tanski wrote:

...

Welcome back! Since Data.Bits is not defined in the Haskell 1998 standard, are we free to change the implementation of Data.Bits? if we are free to change the implementation of Data.Bits, would it be all right to change the operation of rotate, rotateL and rotateR over unbounded types (to my knowledge, currently only Integer)? I would like to change rotate, rotateL and rotateR to actually rotate (not shift) Integers.

-Pete _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Sep 19, 2006, at 3:38 PM, Lemmih wrote:

On 9/19/06, Peter Tanski wrote:

...

I don't have a particular implementation in mind but as a general idea it would make the treatment of Integers the same as the treatment of the standard-size bounded ints. A possible implementation might be a stream cipher that uses 128-bit Integers instead of 32-bit ints (bitwise rotations have been used in more than a few stream ciphers). For arithmetic purposes, rotation is also useful for implementing multiplication of finite fields.

Ah, so you want to rotate various bounded integers larger than 64bits? You can do that without changing Data.Bits at all (crypto defines Word128, Word192 and Word256 which are instances of Bits).

The LargeWord module in Crypto is very cool. Before this email I did not know LargeWord defined rotate (maybe it is the version of Crypto I have--3.03?). -Pete

On Sep 19, 2006, at 3:28 PM, Neil Mitchell wrote:

Hi,

...

Welcome back! Since Data.Bits is not defined in the Haskell 1998 standard, are we free to change the implementation of Data.Bits?

No! If you do things like this, randomly changing the semantics of functions, people will come round to your house with burning pitch forks!

Or, if they reside across the Water, they might simply refuse to use my program. The problem with Data.Bits.rotate, rotateL and rotateR for Integers is redundancy: they are the same functions as shift, shiftL and shiftR respectively. The unfortunate (and possibly buggy) consequence for the unwary might be an unexpected change in the operation of a function that uses rotate, rotateL or rotateR over types in class Num when their Int32's have been promoted to Integers to cover overflow. Otherwise it would be much easier to simply leave it as is (for an array of doubles, where bitwise operations are actually performed arithmetically, rotations would be difficult).

If you want to have functions with new semantics, its probably a good idea to give them new names, or do something else to stop changing existing programs.

Certainly. The reason I asked about Data.Bits was that it is not defined in the Haskell98 standard--I couldn't add IntegerRotate to Prelude, and Data.Bits is a library. In any case, I think the general response is that (a) specious idea or (b) already done in other libraries. -Pete