The Theory of patches-vector
liamoc.net
liamoc.net
data Edit a = Insert Int a
| Delete Int
given that a Delete only needs the place of deletion and a Replace is a Delete followed by an Insert?- Insert Int File == "create file"
- Delete Int File == "delete file"
- Replace Int File == "patch file"
Removing and Inserting a file each time it changes, while technically correct is probably not what you want.
The nice thing about what Liam proposes (and type classes in general) is that it doesn't matter what we each interpret `a` to be.
It uses both Haskell and C++ for examples, although for best effect it'd help if you could read (basic) haskell types. Or maybe not, I read it after learning haskell so I find it hard to just how it is from a just C++ perspective.
Also, the writer of the article worked on google wave.
Would like to know for example how his choice of edit operations and requirement of properties compare with let's say share.js's: http//github.com/ottypes/docs (which was also written by an ex-google wave intern). Explaining the subtle differences between OT implementations and what new advantages his theory brings is more interesting IMO.
Patches-vector seems to be different to ottypes for example in that ottypes have predicted what types you would want to synchronize and provides you a correspondig OT type for each of them. What if I want to synchronize binary data or javascript objects or some other weird thing? If equality is defined for my object the library shouldn't need to make any other assumptions.
Besides this practicality though, I think the whole point of the article is that one can mathematically reason about patches-vector.