Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception thrown when using finiteBitSize that evaluates its argument #116

Open
chessai opened this issue Jun 21, 2020 · 1 comment
Open

Comments

@chessai
Copy link
Collaborator

chessai commented Jun 21, 2020

In the Bits and FiniteBits documentation, bitSize, bitSizeMaybe, and finiteBitSize say that they do not evaluate their arguments. This makes sense for fixed-size types. For something like ByteString though, we need to get the length of the ByteString (e.g. finiteBitSize x = 8 * B.length x). However quickcheck-classes makes the assumption that finiteBitSize will never evaluate its argument, since it passes undefined to it everywhere. It is not clear to me that the documentation for Data.Bits is indicating that a valid implementation of these functions must not evaluate its argument, or if when defining these classes, only fixed-width types were in mind (and not necessarily just finite-sized types, like strict ByteString).

@andrewthad
Copy link
Owner

The documentation of finiteBitSize reads:

Return the number of bits in the type of the argument. The actual value of the argument is ignored. The function bitSize is undefined for types that do not have a fixed bitsize, like Integer.

I've always read this to mean that bitSize must not evaluate its argument. That's what every instance in base does. When Bits was originally written, at least one variable-width type must have been in mind: Integer. However, I find using Bits for variable-length types dubious in general. For the hypothetical ByteString instance, what would .|. and .&. do? Truncate to the length of the shorter argument? See this reddit thread, where Edward has some thoughts on the topic, and see haskell/bytestring#110, which the thread references.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants