Quick update: The design work I’ve been absorbed with the past few weeks feels like it’s at a pretty good stopping point for now. Working through the well-typed editing story was really satisfying since that has felt like a big unknown for the project.
This post describes a design for how to make large-scale edits to a Unison codebase, while ensuring these edits produce code that is well-typed. The approach I’ll describe here is simple, implementable, and has some nice properties:
This post describes the design of an API for distributed evaluation of Unison programs, and for describing, deploying, and executing distributed systems written in Unison. The API I’ll propose here is simple, powerful, and quite easy to implement given the assumptions made by Unison. (I would not be surprised if an initial implementation took less than a week.) In this API, we get to simply declare that a computation be evaluated at a remote node. That computation can be any expression whatsoever in the Unison language, and any needed dependencies of that expression not already known to the remote node will be synced automatically. And this sort of transport never requires any boilerplate plumbing code, manual parsing or serialization (though we can if we wish override wire formats easily). Sounds awesome, right?
Picture this: you’re waiting on some code to compile. You’re using one of those fancy package managers and/or build tools, all your dependencies are compiled and/or installed automatically!! Yay! Right? Meanwhile, there’s screenfuls of text scrolling by your terminal, often at alarming speeds… there’s
configure checking for the presence of like 100 different system headers… or something (come to think of it, does anyone actually know what all those checks are for??) … now there’s some Haskell code being compiled, more screenfuls of text… oop, some code just randomly downloaded from the internet… now some tests running. Seems this dependency has some “doctests”, which means it’s actually parsing and running Haskell code embedded as comments in the code. Gee, that’s rather silly… why is this build process even running the tests if I haven’t modified the code?? I wonder if there’s some sort of flag to disable that. You know what, forget it, just let the damn tests run, by the time I… oop, now it’s installing and some huge C library, what… on earth? I know I’m going to be using max like .01% of that library in my code, why do I have to download and compile all of it up front??! This is getting ridiculous. A few minutes later… Oh, geez, random bloated C dependency I won’t even use is missing some obscure file and crashes during the build… apparently my environment wasn’t configured properly. You stupid computer!! Why did you even start ‘building’ if the program was effectively ill-typed?? You just wasted like 10 minutes of my time when I could have been actually creating something! Google searches… trying various stuff. Hmm, maybe I’ll try IRC. No surprise, your question gets ignored in IRC… multiple times, while some people argue vehemently about the color of the bikeshed. (Blue! No, red!!) Five hours later, you’re mentally checked out and strongly considering a career switch to basket weaving.
This is just a quick update. Having looked at the various GHCJS options for writing the editor, the one that looks the most interesting to me is Reflex-DOM, so it’s the one I’m going to be tinkering with first. I’ve got it working with the build and have successfully got “Hello World” running in the browser via GHCJS and Reflex-DOM. Amazingly, it is actually compiling all the Haskell code in shared to JS. The build process isn’t quite as nice as I’d like… which somewhat promped the last post.