Potential Network SIG

[Johan Tibell]

On Sun, Aug 23, 2009 at 12:43 AM, Duncan
Coutts<duncan.coutts at worc.ox.ac.uk> wrote:
> 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