Data.ByteString.break seems to interpret the predicate backwards

[Yuras]

According to the docs it should return the longest prefix which does not satisfy the predicate. In ghci:

ghci> Data.ByteString.break (== 32) "hello world"
("hello"," world")
ghci> Data.ByteString.break (/= 32) "hello world"
("","hello world")

MicroHs does the opposite:

> Data.ByteString.break (== 32) "hello world"
("","hello world")
> Data.ByteString.break (/= 32) "hello world"
("hello"," world")

I discovered the issue by running the test suite of scanner package: Yuras/scanner#14
I'm also missing Data.ByteString.Unsafe (scanner uses only unsafeChrunsafeDrop from it, so not a big deal) and the whole Data.ByteString.Lazy thing.

[augustss]

I've fixed the break bug and added Lazy (which are actually just strict).
I'm not going to add Unsafe unless there is a really compelling reason. It has a lot of weird stuff in it.
Is your code really that performance critical so you need to use unsafe functions?

2cdcd67

[Yuras]

Thanks!

Is your code really that performance critical so you need to use unsafe functions?

It's in a tight loop, so yes, performance is critical in this case. And other packages (notably hedis) rely on it.
But it's fine, I can live with a bit of CPP for now.

[augustss]

I added the parts of Data.ByteString.Unsafe that make sense.

I'm surprised that you can see a difference between drop and unsafeDrop. The generated code should only differ in a compare and an (untaken) jump. Perhaps GHC generates bad code for drop.