I’m going to update this post when I have a video to show, but I’ve hooked up a number of additional editor interactions, including evaluation of any term as well as beta and eta reduction. I’ve also hooked up the global term search, so the explorer shows type compatible terms in local as well as global scope. The explorer now shows terms which are ill-typed but which match the search query. I also made a number of tweaks to the editor interactions to feel more fluid.
When programming in a language with a nice type system, you often have the option of defining ‘smart’ data types which bake some invariant in as an index of the data type. But sometimes, it can be better to keep your data types dumb, and layer on invariants after the fact. The lesson generalizes, but I’ll show an example—well-formed lambda calculus terms:
I didn’t get a chance to put together a post on Friday, but I made some decent progress. Here’s a short recording of an editing session:
As I mentioned in week 0, the Unison node is written in Haskell and has an implementation of the Unison language, its typechecker, and any primitive functions. It exposes an API over HTTP. Last week, I worked on some of the Unison editor interactions, but I was working somewhat in a vaccum since the editor wasn’t yet connected to the Unison node. I spent this week actually getting the editor and the node talking to each other, and refining the node API a bit in the process.
I spent this week working on a very basic editing layer for the Unison editor. Previously, I’d implemented logic for how to display a Unison panel, including embedded graphical views, but had no way of actually editing these panels. Time to do something about that!