[Haskell-cafe] FP design

[Jonathan Cast]

On 7 Nov 2007, at 11:26 AM, Donn Cave wrote:

> I have been working on a little Java project lately at work, by way
> of an introduction to the language, and naturally I often have cause
> to regret that it isn't Haskell instead.
>
> 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!
>
> 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?

That would be my ideal: protocol layers implemented as functions over  
lazy lists.  Naturally, those compose very cleanly (at least in a  
pipeline-like fashion.  Combining that with running protocol modules  
in serial (e.g., using some standard initial authentication protocol,  
then switching to something else) is a bit more complicated (but  
certainly very doable)).

jcc