[darcs-devel] add get_slurp_context, get_slurp_context_maybe, ... [7 patches]

[David Roundy]

On Wed, Jan 05, 2005 at 10:35:17PM +0100, Tomasz Zielonka wrote:
> On Wed, Jan 05, 2005 at 12:40:47PM -0500, David Roundy wrote:
> > I'd also much rather see this implemented as a monad.
> > See my response to Ian's lazy parsing patch for a discussion of where I'd
> > like to see these sorts of things go.
> >
> > I also find these names a bit confusing.  Could we perhaps get by with
> > something like
> > 
> > newtype SlurpMonad = SM (Slurpy -> Maybe Slurpy)
> 
> You probably mean something like this
>     newtype SlurpMonad a = SM (Slurpy -> Maybe (Slurpy, a))

Right, that's more like it.  Although I suppose we really ought to use
Either so we could report error situations a bit more nicely.  I'd rather
avoid StateT, mostly because I'm just not as comfortable with it, and have
a feeling that it's a bit more featureful than we want.  (Which may be
completely incorrect.)

Actually, in order to deal with things like file deletion, we might want to
make the type something like

data SlurpState = SL Slurpy | NoSlurpy | SlurpError String

newtype SlurpMonad a = SM (SlurpState -> (SlurpState, a))

Then we could express slurpy deletion in a straightforward way.  Perhaps
we'd want something more sophisticated, if we want to allow exception
handling and "catching" of exceptions when a SlurpMonad fails... which
maybe means we do want something like StateT, it's just that I've not used
StateT before.

Maybe we want something like

data SlurpState = SL Slurpy (Maybe IOError)

which would allow us to throw IOErrors just as if we were a real IO
monad...

> > modifySlurpy :: Slurpy -> SlurpMonad () -> Maybe Slurpy
> > modifySubSlurpy :: FileName -> SlurpMonad () -> SlurpMonad ()
> 
> Nice idea, but your modify* functions can be easily implemented with my
> get_slurp_context_* functions. I would rather keep them
> (get_slurp_context_*) as they seem to be more general, or at least more
> primitive. Of course they may become inadequate if you use a different
> definition of SlurpMonad.

I guess the problem is that your get_slurp_context_* functions feel
backwards to me.  I can see their logic, but I'd rather pass "modify" a
function which I want to apply to a particular monad than get as output a
function that replaces a given slurpy.

The key question I'd say is in what I'd like to see exported from
SlurpDirectory, and really don't want to export your get_slurp_context_*
functions, since they seem to have more potential for misuse, and a monadic
export would make it easier to safely create Slurpy-modifying functions
outside of SlurpDirectory.

> > So far, I haven't really understood the get_slurp_context_list, so I'll
> > want to understand that before applying.
> 
> Actually, it seems to be unnecessary. It just appeared as a natural
> specialisation of get_slurp_context_generic. It allows to replace a single
> slurpy with zero, one or more slurpies. The zero and one cases are already
> covered by get_slurp_context_maybe, and I don't see any use for the "more"
> case. So, we can probably safely remove this function.

I see.  It sounds like it would be useful if we wanted to introduce a
"copy" patch type, but that doesn't seem like something we're likely to
do--it has a nasty inverse, the identical file merge.
-- 
David Roundy
http://www.darcs.net