framework for composing monads?
Manuel M. T. Chakravarty
Sun, 18 Feb 2001 15:01:18 +1100
Elke Kasimir <firstname.lastname@example.org> wrote,
> On 16-Feb-2001 Manuel M. T. Chakravarty wrote:
> > Elke Kasimir <email@example.com> 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
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
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
> 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