Hey everyone, Rúnar here. It’s been a while since our last update. We’ve been busy.
Meanwhile, we’re making steady progress on the implementation, working mostly on the Unison codebase editor. Here’s what you get now when you start up
From here, you can explore and manipulate your Unison codebase. You’ll note that Unison first creates a branch called “master”. A branch is really two things:
Right from the start, the master branch contains a number of predefined names for builtins. You can query the contents of the codebase using fuzzy matching:
The codebase knows the type of every definition, and later on we’ll add the ability to query by type.
Oh, and we have tab completion already.
Instead of having a REPL in the traditional sense, Unison is watching for changes to
*.u files under the directory in which it’s started. I’ll open a file called
scratch.u and type a Unison definition into it:
If I save the file, my Unison session immediately shows this:
Note that it says it’s “evaluating any watch expressions”. I can add a watch expression just by adding a line that starts with
> to my file.
If I save again, Unison comes back with the evaluated result of this expression:
I’m happy with that, so I’ll ask Unison to add
replicate to my codebase:
If I had put more (well typed) definitions in my file, Unison would have happily added those too.
replicate is in my codebase, I can actually throw away the scratch file. If I need the definition of
replicate again, I can always ask Unison for it:
We really want to allow Unison developers to use good tools they’re already familiar with like their favourite text editor, and Git. To that end, we’ve made it so that the codebase is just a bunch of (binary) files that can be versioned with Git.
Under the bonnet, Unison creates a directory called
.unison which contains the codebase. There are three subdirectories here (currently); one for branches, one for type declarations, and one for term definitions. Under
terms, we have one directory per hash which contains the compiled definition as well as any metadata.
Since everything is indexed by hash, you’ll never actually change any file, so Git merge conflicts should never happen.
See the Codebase Editor design document for more information.
We’re currently adding more features to the Codebase Editor. Right now we’re making it easier to edit existing definitions that have a lot of dependencies, through a kind of structured refactoring session.
Here’s the feature set we have so far:
comments powered by Disqus