Paul Chiusano

Functional programming, UX, tech, econ


Consulting services

I offer Scala and FP consulting services. If you're interested in working together, please contact me.

About my book

My book, Functional Programming in Scala, uses Scala as a vehicle for teaching FP. Read what people are saying about it.

Popular links

Unison: a next-gen programming platform the worldwide elastic computer (coming soon)
Type systems and UX: an example
CSS is unnecessary

Unison update 2: connecting the editor to the node

[   fp   unison   ]            

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.

Sadly, I don’t have a demo to show. At one point, I had a round trip sucessfully working, with the editor getting live info from the typechecker, but after that I decided to rework some of the node API to better facilitate the interactions I wanted. I’ve just completed that work today but haven’t hooked the changes back up to the editor. I hope to have something more compelling to show next week.

One of the questions I was thinking through on the node API is how to handle search, and at what scope to do this search. In Unison, terms are uniquely identified by a nameless hash (more on that in a later post) and don’t live in packages or modules. Instead, we may search for terms in various ways, including by “name”. A term may have multiple names, and different nodes may refer to the same hash with different names as names are just metadata stored separately. (A “package” could be a concept, but again, it’s just a metadata thing which points to a collection of hashes) This raises interesting questions, though: if the user has clicked on a node to edit it, what completions should they be shown? Here are some possible answers:

In raw text editing, it’s necessary to disambiguate references with explicit imports. Some IDEs will automate this for you, but the model is the same; the presentation of the program must disambiguate user intent, leading to 50 lines of imports at the top of every “file”, where its often arbitrary how codebase is split up into files. In a semantic editor, we can dispense with the ceremony of imports and instead let the user disambiguate at the point of reference. Here’s a very simple proposed interaction:

Notice that unlike using something like Hoogle “manually”, we don’t have to enter the type, since the editor knows the type of the current edit location and can supply that information for us! Thus, we just focus on specifying whatever metadata we’d like to search by.

There are some further refinements to this basic interaction to improve the ability to quickly refine our search. I’ll discuss these in a later post.

Looking forward to next week!

comments powered by Disqus