-
Notifications
You must be signed in to change notification settings - Fork 137
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
Sliced interface for ShortByteString #541
Comments
I'm reluctant to extend I think pushing forward haskell/primitive#354 and #410 is a more sustainable approach: when merged, |
In my opinion implementing functions directly on any :: (Word8 -> Bool) -> Slice -> Bool
any k = \Slice {ba, off, len} ->
let
w = indexWord8Array ba
go !n | n >= len = False
| otherwise = k (w n) || go (n + 1)
in go off and now any :: (Word8 -> Bool) -> ShortByteString -> Bool
any f = Slice.any f . asSlice So most of the code is just moved instead of duplicated, and I don't think it would be that much harder to maintain, but of course that is your decision. I think adding this type would help unify |
@oberblastmeister that's understandable goal, but as long as @sjakobi what do you think? |
I went looking through |
Well, More generally, |
If the cost of copying some bytearray is significant, it usually makes sense to tell the GC not to copy it, by pinning that bytearray. So I don't find the idea of sliced-unpinned-bytestring all that persuasive on the face of it. (Of course, But in many cases I expect the observed "copying cost" to actually be dominated by the allocation cost of the buffers in which the copies are placed. And unlike copying in itself this is unaffected by pinnedness. The allocation overhead for I've been thinking for a while about removing most of the near-duplication between our |
It's from
Sounds good.
How would you do this? Something like type classes? |
Type classes can do this, but then un-specialized versions of every function will be generated even though they should never be used. Backpack is perhaps the "correct" tool for the job, but it's not available with the older versions of GHC and Cabal still supported by bytestring, and would also probably require import cycles to use in this way. So I had in mind to use CPP to share the implementations, if/when I get around to this. |
I think we could take some inspiration from byteslice. This would also address #193, by expanding the api for
ByteArray
based types instead of changingByteString
to useByteArray
.The docs for
ShortByteString
sayHaving a sliced
ShortByteString
would allow using aByteArray
based type in public APIs, similar toByteString
.The text was updated successfully, but these errors were encountered: