Patch theory thoughts, part I

So, I still don’t know whether I’ll actually end up writing a gobby clone in Haskell. But it’s already been a wild ride thinking about the theory behind it and some of the issues involved, and over the next few posts I’d like to share some of my thoughts, complete with illustrative code, in the hopes that others will find them interesting or inspiring. Will this be just a rehashing of stuff that someone else has already written about in much more depth? Will it be an important contribution to the topic? Frankly, at this stage, I don’t really care. =)

I’ll get to the fun stuff soon; today, I’d like to start out simple by just responding to a few of the comments on my previous post.

First, Creighton Hogg wondered about using darcs as the backend of such a concurrent editor, and whether it would run into issues with the known performance problems with darcs. Allow me to first clarify that I am not thinking about creating a concurrent editor backed by darcs, but rather one which is backed by the theory behind darcs. It’s still a fair question, though: mightn’t my editor exhibit the same algorithmic problems that causes darcs performance problems? The answer, as it turns out, is no: darcs exhibits performance problems in the specific case of merging conflicting patches, but in a concurrent editor (the model I’m interested in, at least) there’s no such thing as conflicting patches! This is a very important difference and I’ll talk about this, and its theoretical implications, later. In any event, darcs 2 reportedly fixes the performance problems anyway.

Tim suggested some sort of GUI interface for darcs — I think this is a great idea, but in my opinion doesn’t come anywhere close to filling the same niche as a collaborative editor. A collaborative editor allows for much more freedom, and much more…well… collaboration. For example, you could change some code and put a little comment next to it saying “is this right? Or should it be like XYZ?”, and someone else could respond to the comment, or change the code, and so on. No one would do that via darcs; the social assumption is that each darcs patch you make is correct (to the best of your knowledge), so there’s not as much room for experimenting and getting feedback from others. Anon also questioned the worth of this sort of project, claiming that collaborative editors don’t actually get used all that much, to which I would reply: maybe the reason people don’t use collaborative editors very much is because good (and free) ones don’t exist.

sclv, Eric Kow, and the Edward linked to some interesting research on the topic, which I’ve started reading a bit but hope to look into in more detail soon.

mgsloan is working on a cool Haskell editor project (screenshot) — although as Christophe Poucet points out, it would not work well with a collaborative model due to its use of zippers to hold buffer contents. But I’m glad there are other people out there who know how to make cool-looking GUIs, since I sure don’t. =)

Finally, it turns out that I’m not the first person to have this idea! Christophe (along with Ivan Tarasov) worked on the beginnings of a system called Splatch at last October’s Haskell Hackathon. It’s pretty neat, although (as I have expressed to Christophe, rather incoherently, I’m afraid) I believe in its current state it has a few fundamental theoretical problems. Over my next few posts I hope to be able to expound on this a bit more, although my focus will not be on evaluating Splatch per se, but on describing my explorations in patch theory in general, and as it might apply to a collaborative editor in particular.


About Brent

Associate Professor of Computer Science at Hendrix College. Functional programmer, mathematician, teacher, pianist, follower of Jesus.
This entry was posted in haskell, learning, projects and tagged , , . Bookmark the permalink.

4 Responses to Patch theory thoughts, part I

  1. Nick Burlett says:

    I don’t agree that there are no conflicts in a collaborative editing system. Any good collaborative editor is going to support editing over the network, and this introduces delays. It would be very easy for a single dropped packet to introduce a long enough delay for two users to have made conflicting changes. Other, more serious network blips could have larger problems.

    I look forward to hearing your thoughts on this in a future post.

  2. i might be interested in helping with this project, in whatever limited way i’m able to. i have neither a lot of time nor a lot of skill to offer, but certainly a lot of willingness to do what i can and learn more along the way!

  3. Creighton Hogg says:

    I apologize for my comment being poorly worded. I was not implying that you would build it upon darcs, but I thought you intended to use the same theory.

    I’m a bit confused though as to how you wouldn’t ever have conflicts in a collaborative editor. I’d appreciate hearing a bit more about that.

  4. Pingback: Patch theory, part II: some basics « blog :: Brent -> [String]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.