On Sun, Aug 23, 2009 at 12:43 AM, Duncan
Coutts
On Sat, 2009-08-22 at 21:26 +0300, taruti wrote:
3) Use Bytestrings (and have corrosponding .Lazy modules) for efficiency. As in network-bytestring, any new API should be performance concious enough to avoid String.
Ambivalent here. Does it make more sense to have a send :: StringLike s => ... or sendS :: String -> ... sendBS :: ByteString -> ... sendLBS :: L.ByteString -> ...
I've never understood why people want these type classes. Just pick the right one. Each of those types has functions for converting to each other. Let the caller do the conversion if any needs doing, it's just a function call.
Arguably, ByteString is the right one, at least for the lower level binding. ByteString map well to the types used by the underlying system calls and it is semantically the right type. I can see a reason to provide both the strict and the lazy version as going from lazy to strict might be inefficient as it involves copying. This is why network-bytestring supports both.
Also if we have separate functions we need yet another set of functions when Text is ready.
Which also comes with functions for converting to ByteString or String.
I'm not even sure what sending 'String's or 'Text's would mean without specifying an encoding. We shouldn't be afraid to use composition to prevent a combinatorial explosion i.e. don't have a sendAsUtf8, sendAsUtf16 but instead do send $ Text.encode Utf8 "myString" Cheers, Johan