next-generation programming language, currently in development

Twitter . GitHub . RSS

How laziness brings good query performance without an insane black box optimizer

I did a writeup of the Unison persistent data API last time. After writing that I was feeling inspired and decided to do some implementation work to convince myself the API was implementable and could be made efficient. A lot has come out of that, and this is a writeup. This post has three parts:

full post

Initial sketch of the Unison persistent data API

Also see part 2 and part 3

full post

The editor is really coming together!

Even though the editor is just a small piece of the overall platform, having a v1 of it is super important. Without a way to create and interact with Unison programs, there’s no way to see or get at all the amazing functionality the platform can offer.

full post

Building the fancy autocomplete widget for use in the editor

I’m deep in the middle of implementing the design discussed in the earlier post. The ‘navigation’ mode stuff we’ve seen before, it’ mostly done and shown here. The other mode is the ‘explorer’ mode. You navigate around, select a subexpression for editing, and up pops a crazy advanced autocomplete box with a ton of functionality, which is what I’ve been building (have just finished v1, actually), learning a lot about Reflex in the process. It’s a complex component, with a lot of requirements:

full post

Eliminating redundant parentheses

I was thinking a little bit more about how to nicely layout expressions. In Unison, the user doesn’t explicitly determine how expressions are laid out down to the level of individual line breaks and spacing. The layout engine handles most of this and the user only controls how particular functions render when applied to arguments.

full post