Subject: Re: [Haskell-cafe] Bytestrings vs String? parameters within package names?
From: Henning Thielemann <[email-masked]>
To: Marc Weber <[email-masked]>, [email-masked]
Date: Thu, 05 Feb 2009 12:32:43 +0100

Marc Weber wrote:

> the cabal file:
> 
> 
>   flag bytestring
>     Default: False
>     Description: enable this to use Bytestrings everywhere instead of
>     strings
> 
>   [... now libs and executables: ...]
> 
>     if flag(bytestring)
>       cpp-options: -DUSE_BYTESTRING

No, it's a very bad idea to change the API according to Cabal flags. 
Other libraries importing your one rely on a particular API when they 
specify Build-Depends: hslogger.
Better use type classes to unify the operations on ByteString and 
String. I think it would be great if there would be a library which 
provides this unification since it is needed so often. On the other 
hand, the needed operations may be too application specific and there 
might be more type classes that are reasonable. A too big type class may 
exclude other interesting types. With all functions declared as inline 
(you can also attach INLINE to instance method definitions) I assume you 
will also get no performance penalty, because your programs will then be 
specialised to the string type that the user needs. And this way you may 
easily extend to other types than String, ByteString, ByteString.Lazy.