framework for composing monads?

[Manuel M. T. Chakravarty]

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

> I'm planning a new cli/odbc-based database connectivity library for
> Haskell 98 and want to manage hidden state (various management 
> information) on the Haskell side.
> 
> Some libs. i.e. for gui, extend the IO monad for this using some 
> "start" function:
> 
> main :: IO ()
> main = start prog
> 
> prog :: GUI ()
> ...
> 
> I could do the same with my library, but then it is difficult to combine,
> for example, Gui operations with Db operations.
>
[...proposal for standardised monad transformers...]

Personally, I would stick with the IO monad.  As you have
illustrated, a rather heavy mechanism is needed for
combining state transformers and your are getting into
rather complicated overloading and typing issues.  The
result of which are at least that when a user of your
library gets a type error, it will probably be cluttered
with cryptic contexts and such.

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.  Then, all your operations can work in the
plain IO monad and you have no problem combining with other
libraries using the IO monad.  In fact, it is actually
possible to argue that this is a clean solution, because all
you are doing is to extend the state maintained by the IO
monad.

Cheers,
Manuel