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/
Seems like identifying your library with a git tag would drop that risk to zero.
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?
Have you ever had problem where two of your dependencies are each using a different version of the same library? Or have you ever wanted to incrementally upgrade an API so that you don’t have to change your entire code base in one fell swoop? That is where things like Unison or scrapscript can make it very easy.
One reason for multiple versions of a library in a project is that the project wants to use 2 different dependencies, which themselves depend on incompatible versions of a third library.
I think it is something like Hoogle for haskell but instead of looking for the types of the functions you look for a hash of some kind of canonical encoding of the definition, so it is like an encoded knowledge graph but you should have to give rules in order to construct that graph in a canonical way.
Edited: What I thought was wrong, anyway the idea of above could be useful for something like copilot to complete definitions.
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/