Potential Network SIG

[Duncan Coutts]

On Mon, 2009-08-24 at 09:59 +0200, Johan Tibell wrote:

> > 6) Integrate with the rest of hackage.
> > This means instance of PrettyClass, Parsec, and Binary.  I noticed a
> > number of parsing utilities for IP addresses - lots of duplicated
> > effort here.
> 
> I must disagree here. We don't want hard coupling to lots of other
> libraries. i.e. we don't need convenience functions like:
> 
> get :: Socket -> Binary a
> 
> These ends are better reach by the client writing the glue code. It's
> easy to get a combinatorial explosion in the number of functions if we
> try to provide an integration point for each library out there.


Yes, I think this is a trap that we often fall into, that we think we
make libraries better by providing exactly the one function that people
need, in some kind of "high level" "all in one" operation.

As an example, I'm going to pick on Don because I know he can take
it ;-).

The download package provides:

openURI :: String -> IO (Either String ByteString)

which is great, but also these:

openAsTags :: String -> IO (Either String [Tag])
openAsXML  :: String -> IO (Either String [Content])
openAsFeed :: String -> IO (Either String Feed)

which are all instances of (roughly) this pattern:

openAsFoo = Foo.parseFoo `fmap` openURI

The point is:


  *** don't fear the composition!! ***


Let the user / caller do the composition. The API is simpler and easier
to understand if the user does the composition rather than providing
every use case. Also the package dependencies are much simpler.

Sure, point out in the docs that the user could use it that way with
other libs but don't provide every composition in the name of
convenience.

A Microsoft blogger has a nice short (and rather sarky) article on this
topic:

"Programming means that sometimes you have to snap two blocks together"
http://blogs.msdn.com/oldnewthing/archive/2009/08/04/9856634.aspx


Duncan