[darcs-users] Re: "Patch" plugins

Mark Stosberg mark at summersault.com
Wed Feb 22 03:06:51 UTC 2006


On 2006-02-18, Geoffrey Alan Washburn <geoffw at cis.upenn.edu> 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.

Yes, this has been discussed a number of times in the past. 

> 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.

XML in particular has been given attention. Here's one reference:
http://www.abridgegame.org/pipermail/darcs-devel/2005-July/002947.html

> 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).

I don't get too excited about the "pluggable patch architecture",
because it effectively can create lots of special purpose dialects
of darcs that don't play so nice together. 

> 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.

One of the key limitations it seems is that patches by reversable, which 
makes less sense in some contexts, and is more difficult in others. 

> 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.

I can see the value for special purpose patches types for specific
uses, I'm just not excited about the complexities that might bring if
incompatible patch variants become popular. 

    Mark

-- 
http://mark.stosberg.com/ 





More information about the darcs-users mailing list