Tag: compiler

In my various efforts to develop new programming languages, I’ve occasionally looked sidelong at linear types, as something that looks like it could be really useful if it wasn’t so incredibly cumbersome.

And now some folks have come up with a way to make them much easier to use[^1]! Or at least that’s the hope. This past week I’ve been trying to implement their execution model into a new programming language, to get a feel for what it’s like to actually use. Check out my field notes, if you’re already familiar with the paper.

For an overview of the paper this is based on, check out this post.

Here are my notes about trying to implement a linear/flow language in typescript, compiling to javascript. It uses runtime checks to enforce lienarity; so far there is no type checker.

Update 2025: “The haters said I couldn’t do it. And they were correct. Honestly great call from the haters.” 😄 yeah so I tried implementing this, and was in fact a bad user experience.

What if type inference felt like a real-time conversation, instead of emailing code back and forth?

With type inference, compilers are faced with a difficult task: intuiting what types a user had in mind (but didn’t write down) while writing some code. It all falls apart when the types that the algorithm assigns are different from those the user expected, and especially so when the type error reported is far away from the site of mental mismatch.

For the web-based everything notebook that I’m working on, I’ve been writing backend hookups to various programming REPLs, including IPython and Gorilla. I wanted to be able to evaluate rust code as well in this notebook environment, and so I set about writing a simple server that would compile up a string in rust when asked. This proved do have a couple of gotchas, so I thought I’d air my thoughts here.