allocationPolicy = 23484
-- two usages of allocationPolicy
foo = allocationPolicy + 1
bar = allocationPolicy + 99
You then later realize you want different allocation policies to be used in different parts of your app. You first might want to rename the existing `allocationPolicy`: move.term allocationPolicy defaultAllocationPolicy
At this point, all the code still references that hash, which now has the name `defaultAllocationPolicy`.Next if (say) you wanted `foo` to reference a different definition, you'd `edit foo`, and introduce:
fooAllocationPolicy = 283
foo = fooAllocationPolicy + 1
Then `update` and you're done. The new version of `foo` references `fooAllocationPolicy` while `bar` continues to reference `defaultAllocationPolicy`.A couple other notes -
* It's very rare for independent implementations to end up with the same hash. It probably only happens for some very simple defintions that exist in base. (Like the identity function, say)
* If a hash has multiple names in your project because you've used `alias.term` to do so explicitly, the pretty-printer picks one using a deterministic rule (it prefers names you've given that hash in your project, then it consults library dependencies). If you really want to give two definitions different hashes even though they are functionally the same, you can introduce a minor change, like an unused binding.
* The type of a definition is part of its hash, so sometimes you might specialize a more generic function with a more narrow type signature, and this gets its own hash.
* The OP is slightly out of date re: patches. We use something simpler now for updates and merges. When you update, we compare the new and old namespace to obtain a diff, which is applied to the ASTs in the namespace. If the result typechecks, you're done. If not, we make a minimal scratch file for you to get typechecking - it will contain the minimal transitive dependents of the change.