A common question about Unison: if defs don’t change, how do you make edits to a definition after it’s already accumulated a bunch of transitive dependents? 1/
Basic idea is similar to “updating” a purely functional data structure - you don’t literally mutate it, but instead produce a new structure which shares much of the old. 2/
In Unison, when you edit a definition, foo, and then do ‘update’ that establishes a mapping between the old hash for foo and the new hash for foo. If the old and new hash have the same type, we can then propagate automatically. 3/
The way update propagation works is this: first we visit immediate dependents of the old and update them to point to the new hash. This alters their hash. We repeat for their dependents, and so on, until reaching leaves of the codebase. 4/
The programmer just types ‘update’ so the amount of work they have to do is the same as if they mutated a text file (see important asterisk at end though). Aside: People have wondered about efficiency of this copying. 5/
Though there are ticks we could play to improve this, even w/ naive impl, amount of copying is related to depth of dependency graph. Dependency chains in codebases written by humans tend to be pretty small. If it were even 100 that would be a lot. 😀 6/
Back to main thread, if the update isn’t type preserving, the ‘todo’ command walks you through a structured refactoring process where the programmer specifies how to update dependents of old hashes. 7/
Once this manual process of updating reaching a “type preserving frontier”, the rest of the way can be propagated automatically. Again, same amount of overall work as if mutating text files. You get a nice todo list rather than a bunch of compile errors. 8/
Very important: throughout this process of refactoring, your codebase always builds and you can run all your code. It’s just that some code still points to “old” definitions until you finish propagating the changes. A Unison codebase is never broken. 9/
Also, these mappings from old hash to new hash are recorded in a Unison “patch”. A patch can be applied to any Unison namespace (not just at root codebase scope). One nifty thing: the patch targets hashes, not names, so it is more broadly applicable. 10/
Ex: Alice pulls Bob’s definition, frobnicate. She doesn’t like the name and changes it to ‘transmogrify’. Bob then fixes a bug in (what he calls) transmogrify. Alice pulls Bob’s patch and applies it which still works even tho her name for the def differs 10/
Overall: same amount of work as before for programmer, codebase is never broken, always well-typed, and runnable. The interface to an unfinished refactoring is a tidy todo list rather than a bunch of (often misleading) compile errors. 11/
Important asterisk: for changes to type declarations, right now all we support is manual propagation. Which can be quite tedious. We are working on fixing this! Nothing fundamental blocking this, But it’s a little more interesting than updating terms. 12/
Important asterisk (cont): basic idea for automatic propagation of type decl updates is likely to use some programmer provided mapping between constructors of old decl and those of new decl. 13/
Correction of typo here that should read “Bob fixes a bug in (what he calls) frobnicate”
