[Haskell-cafe] FP design

[Donn Cave]

On Wed, 7 Nov 2007, Justin Bailey wrote:

> > So I'm the one user in a thousand that will want to provide my own I/O
> > functions, for example.  In the old world, I guess I would be looking
> > for some extended API where my I/O functions are parameters to the "open"
> > or "init" function, and the IMAP functions take over from there.  In a
> > more pure functional oriented model, could it be an extended API that
> > exposes the IMAP functionality as operations on data, and leaves it to
> > me to deal with the I/O?
> 
> I believe a typeclass could solve this for you. The typeclass member
> functions serve as your interface definition. For example, say "auth"
> was a member function. Then you could implement instances which
> authorized using NTLM, HTTP Basic, etc.
> 
> It's similar to how you'd do the same thing in java with interfaces, in fact.

That auth function is not a bad example, because there are a number of
cross dependencies along the way to authentication.  When you try to design
a generic API that will supports all kinds of authentication, you end up 
with some abominable tangle like SASL, and even then you end up punting
on some of them (where does your SSL certificate go?)  Some of the 
underlying protocols involve more than one round trip (Kerberos), others
need access to the SSL state, etc.

What I'm running up the flagpole here, so to speak, is the notion that
if at a larger scale you write your application protocol engine so that
it just operates on data and doesn't need to take control over "the wire",
that might give you a thinner API, and fewer problems to solve via typeclass.

	Donn Cave, donn at drizzle.com