[darcs-users] darcs patch: Is this Monadish?
Ganesh Sittampalam
ganesh at earth.li
Thu Aug 28 04:50:08 UTC 2008
On Wed, 27 Aug 2008, Jason Dagit wrote:
> Ganesh was helping me with it and he recomended making it a ReaderT so
> that the Repository is hiding inside. In the refactoring I've done so
> far, I didn't take advantage of that, but in principle it should work.
> It almost seems like we could just throw away RepoInState and replace it
> with Repository p. In fact, that's probably what I should do. But,
> then how do you declare IORepo in a way that allows (>>>=) to have the
> right type?
> Oh right, so here was the problem. We don't want to use State because
> you could fetch a previous state and use it later. But, we wanted to
> store the (Repository p), so a Reader works for storing (Repository p)
> since that part doesn't change. That's why we farmed out the part that
> can change to the type RepoInState. I think not storing the Repository
> in a Reader still presents the same issue of needing RepoInState. I
> think without RepoInState we need all the permutations of type changes
> implemented as functions which is yucky :(
Right, so the idea is that Repository p can never change (either in value
or type), because it's just a handle to the actual repository - akin to an
IORef - whereas the changing type of RepoInState is responsible for
tracking what we have actually done to the repo. That's why Repository p
is in the reader part, whereas RepoInState is part of the "typed state".
The point of having Repository p in the monad at all is so that callers
can't suddenly pass in a different repository in the middle of a sequence
of operations; lowerIORepo (which should also take a Reader p as a
parameter) is also unsafe, but the series of operations done by the IORepo
computation you pass to it are not unsafe (as long as the implementations
of the low-level operations are correct).
RepoInState could actually be an empty data decl (using a long-established
GHC extension) since it is a phantom type parameter.
Cheers,
Ganesh
More information about the darcs-users
mailing list