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
_______________________________________________
darcs-devel mailing list
darcs-devel@darcs.net
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
