Proposal: ByteString based datagram communication (Ticket #1238 )

[Bulat Ziganshin]

Hello Duncan,

Friday, April 6, 2007, 3:52:51 AM, you wrote:
> In most situations there is an obvious candidate amongst String, strict
> ByteString and lazy ByteString. In this case, for datagram communication
> the obvious choice is indeed strict ByteString.

you see from the POV of *implementor* and for this case you are
probably perfectly right. but from POV of user, in most cases, speed
doesn't matter and i want to use just the types what are most
convenient for me. if i work with strings here, i want to be able to
get strings from any sources and send strings to any receivers.
learning which libs provide string api, which ByteString one and so on
is not interesting, adding conversions between all those types
clutters the code

it seems easier for me to just import Network if i want to use
standard string type, or Network.ByteString which, i know, provides
exactly the same operations, only on ByteStrings instead of memoizing
which operations was easier to implement in which type due to some
internal reasons

just imagine that we got to exclude concat :: [ByteString] -> ByteString
operation because it's natural return type is lazy ByteString

so for me the best variant is to *implement* these operations using
strict ByteStrings and provide wrappers which deal with other types

automatic conversion of arguments and results using typeclass is
really bad idea, i agree/ may be, it would become better with some
kind of defaulting, where, say, lazy UTF8-encoded FPS will be default
type for such class

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com