Interesting idea, but isn't code addressable already in most languages?
We call them modules/libraries and we pip/npm install them from Github and you can keep track of changes/versions/PRs.
We call them modules/libraries and we pip/npm install them from Github and you can keep track of changes/versions/PRs.
Modules and libraries are addressable based on their names or URI:s.
"Unison eliminates name conflicts. Many dependency conflicts are caused by different versions of a library "competing" for the same names. Unison references defintions by hash, not by name, and multiple versions of the same library can be used within a project." https://www.unison-lang.org/docs/what-problems-does-unison-s...
"Here's the big idea behind Unison, which we'll explain along with some of its benefits:
Each Unison definition is identified by a hash of its syntax tree.
Put another way, Unison code iscontent-addressed. Here's an example, the increment function on Nat:
increment : Nat -> Nat increment n = n + 1
While we've given this function a human-readable name (and the function Nat.+ also has a human-readable name), names are just separately stored metadata that don't affect the function's hash. The syntax tree of increment that Unison hashes looks something like:
increment = (#arg1 -> #a8s6df921a8 #arg1 1)
Unison uses 512-bit SHA3 hashes, which have unimaginably small chances of collision.
If we generated one million unique Unison definitions every second, we should expect our first hash collision after roughly 100 quadrillion years! " https://www.unison-lang.org/docs/the-big-idea/
I guess what I'm not understanding here is the utility. Why is it useful to include multiple versions of a library in a project? Is this a limitation I've been coding around without knowing it?
Edited: What I thought was wrong, anyway the idea of above could be useful for something like copilot to complete definitions.
edit: not memoization, just hashing the AST of a function.