[darcs-devel] Re: Patch "plugins"

[Geoffrey Alan Washburn]

	Would there have been a better forum for me to send this message?  Thanks!

Geoffrey Alan Washburn wrote:
> 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