framework for composing monads?

[Manuel M. T. Chakravarty]

Elke Kasimir <elke.kasimir@catmint.de> wrote,

> On 16-Feb-2001 Manuel M. T. Chakravarty wrote:
> > Elke Kasimir <elke.kasimir@catmint.de> wrote,
>    (...)
> > [...proposal for standardised monad transformers...]
> > 
> > Personally, I would stick with the IO monad.  
> 
> Beyound personal preference, in my case having an "own" 
> monad has some objective advantages:  (a) initialization and 
> clean-up is automatically done in the right places, (b) there are database
> operations (DML) which should always be performed inside of transaction,
> and others (DDL) which should be performed outside a transaction. With
> the help of an (additional) monad context, this is checked at compile time.
> (c) with an additional context for transactions, unadvertantly nesting of
> transactions is detected at runtime.

Re (a): Usually, you have to process command line options
etc, which also provides a natural place for
initialization.  See, eg, the `init' function for Gtk+HS

  http://cvs.gnome.org/lxr/source/gtk%2bhs/gtk/GtkMain.chs

Clean up should really be handled by a finaliser that is
automatically invoked before program termination, but
unfortunately, there is no standard Haskell 98 support for
that.

Re (b) & (c): Yes, these are good points.

> > The from a functional programming point of view certainly
> > ugly, but, on the other hand, very pragmatic solution is to
> > have your database library use `IORef's to maintain your
> > global state.
> 
> It is even acceptable for me to manage the state in C -
> independent of the API design - but then some time there 
> will be the question: Why do I always say that that Haskell 
> is the better programming language, when I'm
> really doing all the tricky stuff in C?...

Sure - therefore, I proposed to use `IORef's rather than C
routines. 

> Consequences: 
> 
> Given that here on the mailing list there is the opinion that 
> "sticking to IO"  is to be preferred, and that a "monad composition" approach
> requires measures beyound one single library, I should probably offer both 
> solutions, the "sticking to IO" solution being the standard, and the other 
> being declared experimental.

Sounds like a good idea to me.  It has an additional
benefit: Existing GUI libraries - like Gtk+HS - which are
based on the IO monad can be used in conjunction with your
library, too.

Cheers,
Manuel