Haskell, Erlang, and Frank walk into a bar – and begin new project to work in Unison

Re: Making a hash of it...?

I guess the chances of a hash collision are so much smaller than the collisions we already have with a combination of name + types that it isn't a priority to worry about.

The second point is probably an advantage - no unexpected changes, the references must be _deliberately_ updated; it also allows parallel testing and stuff in a real environment, and you since you can uniquely identify a function you can easily see if the old one is being used.

Re: Making a hash of it...?

When collisions are detected the hash algorithm is considered broken. For something of deterministic complexity like a function's AST the chances of conflicts of hashe with the AST of another function might even be provable. Basically: a different function that has the same hash, has the same AST.

Re: Making a hash of it...?

1. These hashes are essentially random 512-bit numbers. To get an idea how big a space of numbers that is, imagine a two-dimensional plane with every atom in the known universe on the X axis, then again on the Y axis. A 512-bit hash is basically throwing a dart at a dartboard that size. You are more likely to win every lottery on the planet in the same week, while simultaneously getting struck by lightning and hit by a meteror, than you are to find a hash collision in 512-bit SHA3.

2. I imagine a bug fix is done much the same way it's done in other languages, by shipping new code (which would have a new hash).

waskell?

Re: we don't have to keep running the same tests over and over

Hello, I'm one of the creators of Unison. You are of course correct that if a test has a side-effect then we cannot cache the results. This is going to be the case for things like integration tests. So Unison will not cache the results of all tests. But we can actually tell which tests are going to have side effects and which won't (Unison's type system gives us this ability), and it turns out that most unit tests can be run without any side effects at all.

Your comment of this being an "extreme form of dynamic linking" got me thinking about that. I too have nightmares about dynamic linking and "DLL hell". But I think Unison's approach is actually a form of extreme *static* linking. That is, the problem with dynamic linking is that the address of linked code isn't known in advance--you only have a link which is maybe a name, a version, and an offset. Links can be broken so dynamic linking can fail and routinely does. But hashes in Unison are essentially static pointers into a vast shared memory space. So the referent of a given hash is always going to be at the same address in that space, just like in a statically linked program.

Re: we don't have to keep running the same tests over and over

I agree with your warning instincts, but you've not articulated the problem quite the way I see it.

The problem is not that unit tests might have side effects. After all, it's a paddling if they do. The problem is that unit tests might be affected by things that are not part of the unit test suite at all. In the end, unit tests are themselves just code, and therefore just as vulnerable to problematic thinking as the code that they are testing. There are any number of thinks that someone might assume are constant that are not. I personally observed a unit test that would fail if executed in the vicinity of daylight savings time change.

So maybe I'm being a princess about this pea, but I really like to see that unit test suite run in its entirety on a very regular basis.

Re: Frank

Nah, Frank is "a strict functional programming language designed from the ground up around a novel variant of

Plotkin and Pretnar’s effect handler abstraction".

You've probably already guessed this, but "in Frank, the equational theory is taken to be the free theory, in which there are no equations".

Re: How does this speed refactoring?

Hello, I’m one of the creators of Unison. It’s true that 512 bits (64 bytes) is a bit larger than what today’s CPUs typically use for pointers (8 times larger to be exact), but this alone is not going to contribute significantly to the memory footprint of the typical Unison program (user data is going to do that). We think this is a fair price to pay for the abilities we get from content-addressing code.

Regarding renaming... if you have e.g. a Java library where you’ve named something x, and lots of user code refers to it as x, then if you rename it to y and republish your library you’re going to break everyone’s code. Names are really important in traditional languages. But in Unison, the name is just metadata. You can rename a function from x to y, republish your code, and everyone else’s code still works! Because they weren’t referring to the name anyway. Their code was referencing the hash.

Because of the hashes, Unison knows a lot more about the structure of your codebase than a typical IDE, so we can make refactoring a very controlled experience. They typical workflow in most languages is that you make a change and your codebase is broken until you finish propagating that change (manually) throughout. But a Unison codebase is never broken that way, even in the middle of a refactoring.