I see your point, but if we extend this line of reasoning, every time a new String-based API is created, the author may be looking at having to provide 3-5 separate APIs to handle all the (current) String types available. I think Duncan's proposal of a solution analogous to fromIntegral is correct. Your arguments are applicable to APIs which use Int rather than Integer as a datatype. We don't provide Data.List.Integer for Integer based indexing because we have a simple conversion mechanism in fromIntegral. Likewise, I think the solution for simplifying String interfaces is to provide some sort of convertString utility (such as http://hpaste.org/1276 ). With convertString anybody who wants a String or lazy ByteString interface to Network can simply write their own wrappers using that utility without too much difficulty. As can be seen in the current patch, even without convertString, the wrappers are fairly trivial. Such trivial wrappers don't really warrant cluttering the API so much. On Fri, 2007-04-06 at 18:28 +0400, Bulat Ziganshin wrote:
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
-- Robert Marlow MITS Co-operative Limited http://www.mits.coop/