Re: framework for composing monads?

2001-02-18 Thread Marcin 'Qrczak' Kowalczyk
Sun, 18 Feb 2001 15:01:18 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze: > 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%2bh

Re: framework for composing monads?

2001-02-17 Thread Manuel M. T. Chakravarty
Elke Kasimir <[EMAIL PROTECTED]> wrote, > On 16-Feb-2001 Manuel M. T. Chakravarty wrote: > > Elke Kasimir <[EMAIL PROTECTED]> wrote, >(...) > > [...proposal for standardised monad transformers...] > > > > Personally, I would stick with the IO monad. > > Beyound personal preference, in my

Re: framework for composing monads?

2001-02-17 Thread Elke Kasimir
On 16-Feb-2001 Manuel M. T. Chakravarty wrote: > Elke Kasimir <[EMAIL PROTECTED]> 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

Re: framework for composing monads?

2001-02-15 Thread Manuel M. T. Chakravarty
Elke Kasimir <[EMAIL PROTECTED]> 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" func

framework for composing monads?

2001-02-15 Thread Elke Kasimir
Does someone like to comment on this? 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 ::