Abstracting ByteStrings

A lazy ByteString is an alternative to a String=[Char], where sacrificing some degree of laziness through "chunks" gives much greater performance in many applications. If I remember correctly, we could as well create an IntString, DoubleString, etc by filling the chunk arrays with different types. Now, this might only work for primitive types, but couldn't we extend it by taking a similar approach to NDP? For example, if we have (lazy) ByteString = [Chunk Char], then we could represent, say [Chunk (a,b)] as ([Chunk a], [Chunk b]), etc Is this reasonable? Do you think it would work? Or is all of this subsumed by fusion anyway? -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

On Tue, 22 Jan 2008, Chad Scherrer wrote:
A lazy ByteString is an alternative to a String=[Char], where sacrificing some degree of laziness through "chunks" gives much greater performance in many applications. If I remember correctly, we could as well create an IntString, DoubleString, etc by filling the chunk arrays with different types.
Now, this might only work for primitive types, but couldn't we extend it by taking a similar approach to NDP? For example, if we have (lazy) ByteString = [Chunk Char], then we could represent, say [Chunk (a,b)] as ([Chunk a], [Chunk b]), etc
Given a reasonable Storable instance of pairs you could use: http://code.haskell.org/~sjanssen/storablevector
Is this reasonable? Do you think it would work? Or is all of this subsumed by fusion anyway?

Given a reasonable Storable instance of pairs you could use: http://code.haskell.org/~sjanssen/storablevector
I hadn't seen that before, thanks!

On Jan 22, 2008 6:19 PM, Chad Scherrer
A lazy ByteString is an alternative to a String=[Char]
Careful. ByteString is an alternative to [Word8]. Converting [Char] to
ByteString and back requires an encoding. (Unfortunately, the only encoding
that comes with the bytestring package is lossy.)
--
Dave Menendez

Careful. ByteString is an alternative to [Word8]. Converting [Char] to ByteString and back requires an encoding. (Unfortunately, the only encoding that comes with the bytestring package is lossy.)
Ahh, good point. I guess I almost always just use them to read ASCII, so it hasn't been an issue. But for numeric types, I think this wouldn't be so much of an issue, since the format is more uniform. Chad
participants (3)
-
Chad Scherrer
-
David Menendez
-
Henning Thielemann