[darcs-devel] Patch "plugins"

[Geoffrey Alan Washburn]

I looked at the confirmed ideas and wish-list pointed to by the darcs 
wiki, but I didn't see anything like what I had in mind.  In particular, 
I was curious as to whether any thought had been given to being able to 
design "plugins" to extend the language of "atomic" patches.

At least as I understand from looking at the manual there are a few 
"atomic" sorts of patches "hunks", "binary file modifications", "add a 
new file", etc.  Then there are ways to combine them into larger patches.

However, one annoyance I've had as of late is that most software uses a 
diff algorithm for text and maybe something special, like Xdelta for 
binary data.  But quite a bit of data these days is structured, XML 
being the most popular example.  But another good example are is just
plain old ASCII text.

For example, Subversion, in a really ad-hoc way, allows users from 
having to deal with DOS/Unix/Mac end-of-line conversions.  The thought 
would be to make this into a new kind of "atomic" patch that people 
could choose as a "plugin".

Similarly, XML documents are meaning invariant under quite a few 
operations (even more if you know the DTD or schema, but it would be 
better to start with invariants for all valid XML documents).  One could 
imagine a "plugin" for an XML "atomic" patch that would take these basic 
invariants into account.

Of course, users using these "plugins" would not necessarily be able to 
communicate their patches to others who don't have the same set of 
plugins, but I don't see this as especially onerous.  One might even 
imagine requiring a kind of backwards compatibility mode with all these 
"plugins" such that they can be normalized to the core language of 
patches, but losing some of the advantages (i.e. you don't get end of 
line conversion for free).

There is also the question of how to enforce that "plugin" patches obey 
the theory of patches.  I see that there is already some investigations 
into using GADTs to ensure than invariants are maintained (I have to 
admit that was my favorite part of David's talk at the Haskell Workshop) 
, but even then that might not be enough.  ghc is continuing to push 
forward with making more and more dependent type like features 
available, so perhaps eventually that will be enough.  A more immediate 
proposal, but definitely more radical, would be to start coding up the 
theory of patch framework in Coq, which supports Haskell code extraction.

Anyway, I would be curious to hear what people think about this idea, 
because this is something I'd really like to see in version control system.

Geoff