[Haskell-cafe] FP design

[Levi Stephen]

Donn Cave wrote:

> But in the specific matter I'm wrestling with, the Java library's OOP
> model is, to its credit, allowing me to do some things.  I'm using their
> standard LDAP client library, but swapping in my own function to read
> X509 certificates for the SSL.  Actually, swapping in my own SSL socket
> "implementation", which in my case just calls the standard library SSL
> socket implementation to do most of the work.
> 
> Now it's not like I can't imagine it working better - it may be a little
> fragile, for one thing - but I have wondered what facilities a Haskell
> design could have drawn on to de-couple implementation components like that.
> Let's say you download an IMAP mail client library, and look to see if it
> can operate on a UNIX pipe;  on an SSL socket;  authenticate with GSSAPI
> Kerberos 5  -- when none of those things are supported out of the box.
> (As I have needed, and done, all three of those with the standard Python
> IMAP library module.)  You may also want its I/O operations to integrate
> with some dispatching core, for a GUI.  But of course you also want the
> basic interface to be simple in this area - the IMAP protocol itself is
> complicated enough!
> 

I have similar questions about Haskell abstracting away implementations behind
interfaces as well. I have become used to an approach where I will not worry
about databases/persistence when beginning. I will create an interface to a
database layer (e.g., save(object), retrieve(id), findByName(name)) etc., and an
implementation that uses in memory collections to begin with. Later I will
replace this with database calls.

This also helps in my current project as we support multiple databases. If
findByName requires different SQL on different databases it's easy to have a
different implementation used at run time.

How does this type of approach work in Haskell? or what is the Haskell way to
achieve this?

Levi