next-generation programming platform, currently in development
about

Twitter . GitHub . RSS

New Year's Update



Hey everyone, Rúnar here. It’s been a while since our last update. We’ve been busy.

Spreading the word about Unison

Codebase editor progress

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 unison:

Starting the codebase editor

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:

  1. A collection of names for the hashes in your codebase.
  2. A collection of edits to the codebase.

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:

ls drp

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.

Unison is watching

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:

replicate

If I save the file, my Unison session immediately shows this:

saved scratch.u

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.

replicate 3 lambda

If I save again, Unison comes back with the evaluated result of this expression:

eval replicate 3 lambda

Adding and viewing definitions

I’m happy with that, so I’ll ask Unison to add replicate to my codebase:

unison add

If I had put more (well typed) definitions in my file, Unison would have happily added those too.

Now that 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:

view replicate

Git-friendly codebase structure

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 types and terms, we have one directory per hash which contains the compiled definition as well as any metadata.

Unison codebase structure

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.

More features

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:

unison help

comments powered by Disqus