> In Unison, you're almost never waiting around for your code to build. Why is that?
> Because Unison definitions are identified by their hash, they never change. We may change which names are associated with which hashes (and this is used for Unison's approach to refactoring and code evolution), but the definition associated with a hash never changes.
> Thus, we can parse and typecheck definitions once, and then store the results in a cache which is never invalidated. Moreover, this cache is not just some temporary state in your IDE or build tool (which gets mysteriously inconsistent on occasion), it's part of the Unison codebase format. Once anyone has parsed and typechecked a definition and added it to the codebase, no one has to do that ever again.
> This idea also applies to caching test results for pure computations (deterministic tests that don't use I/O). There's no need to rerun a deterministic test if none of its dependencies have changed!
> The result of this pervasive caching is you spend your time writing code, not waiting around for the compiler.
This is a neat idea but seems dangerous. Any miscompilation will be in the cache forever, and anyone can trigger a new cache entry. Also, does this mean that with every compiler release there will be a full rebuild of the whole ecosystem, or things are rebuilt on demand?
I think this would work better with a formally verified compiler (a compiler with a mathematical proof that it always compiles correctly), or at least a weaker proof such as proving the compiler is deterministic (no easy feat if the compiler is multithreaded) and that the output doesn't depend on the environment the compiler is running on (at very least, that it compiles the same on any OS)
nextaccountic•12h ago
> In Unison, you're almost never waiting around for your code to build. Why is that?
> Because Unison definitions are identified by their hash, they never change. We may change which names are associated with which hashes (and this is used for Unison's approach to refactoring and code evolution), but the definition associated with a hash never changes.
> Thus, we can parse and typecheck definitions once, and then store the results in a cache which is never invalidated. Moreover, this cache is not just some temporary state in your IDE or build tool (which gets mysteriously inconsistent on occasion), it's part of the Unison codebase format. Once anyone has parsed and typechecked a definition and added it to the codebase, no one has to do that ever again.
> This idea also applies to caching test results for pure computations (deterministic tests that don't use I/O). There's no need to rerun a deterministic test if none of its dependencies have changed!
> The result of this pervasive caching is you spend your time writing code, not waiting around for the compiler.
This is a neat idea but seems dangerous. Any miscompilation will be in the cache forever, and anyone can trigger a new cache entry. Also, does this mean that with every compiler release there will be a full rebuild of the whole ecosystem, or things are rebuilt on demand?
I think this would work better with a formally verified compiler (a compiler with a mathematical proof that it always compiles correctly), or at least a weaker proof such as proving the compiler is deterministic (no easy feat if the compiler is multithreaded) and that the output doesn't depend on the environment the compiler is running on (at very least, that it compiles the same on any OS)