[Haskell-cafe] helping you contribute to darcs (poll results so far)

Jeremy Shaw jeremy at n-heptane.com
Wed Aug 6 16:41:23 EDT 2008

At Wed, 6 Aug 2008 19:59:11 +0100,
Ian Lynagh wrote:
> On Wed, Aug 06, 2008 at 11:28:58AM -0700, Jeremy Shaw wrote:
> > At Wed, 6 Aug 2008 10:48:03 +0100,
> > Ian Lynagh wrote:
> > 
> > > I've just had a quick read of
> > >     http://citeseer.ist.psu.edu/prakash92undoing.html
> > > AFAICS this only really deals with the case where there are no
> > > conflicts, and doesn't talk about merging.
> > 
> > AFAIK, the papers do not talking about merging.
> > 
> > They cover conflicts in the case where you want to remove/reorder an
> > older patch which conflicts with a newer one.
> Only in the case where you have already undone the newer one, and thus
> can just remove both the new patch and its inverse, I thought.

That sounds right to me. 

> > Since I don't know the darcs internals or patch theory, I don't have a
> > concept of how much is still missing
> The difficult part is still missing  :-)

Right, but is the difficulty in thinking up the ideas and figuring out
solutions to the problems ? Or is the implementation also neccessarily
very large and complex (even if implemented in my toy code which only
has two operations: 'insert' and 'delete')

I guess the best question is, how far from reality is the theory of
patches as written in the darcs manual:


Is the additional complexity/difficulty in actually implementing
functions like unwind, or is there just a bunch more theory missing
from that page? Would a function like unwind be easier to implement,
if it was done in my toy setting, and if I did not care about
efficiency and computational complexity?


More information about the Haskell-Cafe mailing list