Proposal: ByteString based datagram communication (Ticket #1238 )

[Robert Marlow]

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/