On 9/11/06, Eric Y. Kow <[EMAIL PROTECTED]> 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

_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel

Reply via email to