cdornan / fmt

New formatting library
BSD 3-Clause "New" or "Revised" License
56 stars 6 forks source link

Handle `ByteString`s with fmt operators #9

Closed vrom911 closed 6 years ago

vrom911 commented 6 years ago

It's not easy to deal with ByteStrings in fmt library, as I noticed there is no instance Buildable for it...

UPD: I found byteString :: ByteString -> Builder function from the bytestring package. Probably it can be reexported in fmt?

chshersh commented 6 years ago

I agree that having Buildable instances for both ByteString and LazyByteString would be really convenient! Unfortunately, it's not easy to tell, what should be the default implementation of such instance. Because ByteString is basically a ByteArray (and a lot of problems can be solved if this data type was named properly). It just happens so that very often ByteString is used at utf-8 or ascii encoded text.

Though, it's still not obvious what formatting you prefer... When you format ByteString "ABC" do you want to see [65, 66, 67] or do you want to see "ABC"? But still, you can specify explicit formatting function for ByteString but when you have data type with ByteString inside, like Either Int ByteString it becomes really hard to deal with such data types. Unfortunately, I didn't find formatting functions for ByteString neither in text-format not in formatting library.

My initial guess is that we should have Buildable instance for ByteString. Though I don't really like orphan instances, I don't think this can be avoided for now... I created issue: https://github.com/bos/text-format/issues/20

Maybe we can live with default implementation from ByteString to String using unpack or show and then to Builder. I don't see good solution for this problem...

neongreen commented 6 years ago

I don't think there's a good default here. My gut says that half of the time it's hex and half of the time it's UTF-8 (or rather, for many applications/domains it's exclusively one or the other, and it all depends on what you're writing).

I'll add utf8F though.