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@gmail.com