[darcs-devel] Logging

Jason Dagit dagit at codersbase.com
Mon Sep 11 22:12:35 PDT 2006


On 9/11/06, Eric Y. Kow <eric.kow at gmail.com> wrote:
> On Mon, Sep 11, 2006 at 14:17:30 -0700, Jason Dagit wrote:
> > Although I hadn't mentioned it yet, I was actually hoping that at some
> > point in the distance future we may extend the IO monad to carry
> > around some extra details and at that time logStr could be updated to
> > read the opts from an environment.
>
> I think extending the IO monad is more or less the right way to go (and
> would be better than my unsafe global flags stuff).  It would also be
> handy for the stuff Nathaniel Gray was implementing to pass stuff
> generated by the commands to the posthooks, and maybe also as a clean
> way to return an exit code.

Ah, yes this must have been what made me start thinking about it recently.

>
> I have a repository where I had started to do this by using a state
> transformer and calling the whole thing DarcsIO, but I never got around
> to finishing it.  The code looks like this and could probably be vastly
> improved:
>

I'll just give some of how I might do it.  Just throwing out ideas for
identifier naming mostly.

> type DarcsIO = StateT DarcsStatus IO

type DarcsM = ReaderT DarcsEnv IO

>
> -- the idea is that one day we might decide to make this fancier
> data DarcsStatus = DarcsStatus
>        { dsOpts :: [DarcsFlag] }

data DarcsEnv = DarcsEnv { darcsEnv'opts :: [DarcsFlag] }

(I'm really hooked on that naming convention, but it's not consistent
with darcs codebase so maybe something else would be more natural).

data DarcsEnv = DarcsEnv { darcsOpts :: [DarcsFlag] }

(dOpts ?)

> dliftIO :: IO a -> DarcsIO a
> -- this is trivial for now, but perhaps in the future the darcs
> -- monad transformer stack will grow
> dliftIO = liftIO

liftDM ?

>
> withDarcsIO :: (DarcsStatus -> IO b) -> DarcsIO b
> withDarcsIO job = do d <- get
>                      dliftIO (job d)

withDarcsM ?

> Is the reader monad like a state monad without a 'put'?

Basically, yes.  Reader lacks a way to mutate state, but you can give
a 'local' definition if you want to 'rebind' things.  I think it's
mostly meant for building interpreters.  But, I can't think of a good
argument why darcs would want to destructively (hm...lisp jargon?)
modify it's configuration at run time.  So to me, Reader seemed like
the safer way to go.

It sounds like I should keep plugging away on the logger code and then
show you guys what I have in hopes that we can meet in the middle
about this Darcs IO monad code.

Jason




More information about the darcs-devel mailing list