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!
This was my first week dedicated mostly to working on Unison. Before getting to my update, I’ll give a bit of background on the Unison architecture. There are two pieces: