shalabh
12/12/2025, 12:41 AMshalabh
12/13/2025, 8:54 PM{key1: 'a1'} -> {key1: 'a2'}
b. timeline-2: {key1: 'a1'} -(wrap in a list)-> {key1: ['a1']}
c. merged: {key1: ['a2']}
d. even works if timeline-2 appends 'b1' before merging. merge produces {key1: ['a2', 'b1']}.
3. there is a notion of identity in this model that i’d like to examine. eg when a1 is replaced with a2 the containing structure “remembers” which specific value was replaced by using a unique ID.
a. even for lists, a unique ID is attached to each value so you can figure out how an operation on that value in one timeline applies to a forked list where that specific value has since moved.
4. i feel the idea can be generalized to more than records and lists. consider if we think about a general object V as containing slots that have identity. slots hold values. transformations move slots around, add and remove slots or replace slot values. the projection and retraction methods may need to be supplied by V itself. anyway, haven’t fully worked this out.
5. the paper focusses on small data where each copy carries around the full history, and doesn’t need a central repo. however, the model could easily work with a central repo storing the committed or even parallel timelines for objects. local objects only need to hold zero or small histories with a pointer back to the committed timelines. if we generalize the fork/merge model here, it could apply to even large object graphs, parts of which get forked and then recombined.
overall quite fascinating. there’s a big section on related work i haven’t caught up on.