Here’s a scenario that’s familiar to most programmers: after making a seemingly minor program change in your text editor / IDE of choice, the compiler spews back at you tens or even hundreds of baffling compile errors. Even if you’ve gotten used to this sort of thing, there’s something a little demoralizing about it. I don’t particularly enjoy sleuthing around to figure out the root cause when the compiler is giving me a trail of seemingly unrelated clues. Compilers are often pretty bad at reporting the root cause of the actual errors.
This basic workflow - make changes, submit them to the compiler, and interpret any errors that occur - has remained largely unchanged since the punchcard era. Here’s another way of putting it: we start with completely unconstrained input in the form of raw text. We then submit a blob of this raw text to the compiler, which “parses” the text, and then typechecks it. Of course, most raw text strings are not valid programs – they don’t even parse, let alone typecheck! Thus, over the years, compilers and editors have become increasingly sophisticated at reporting back to the user where and how the user went wrong in this raw text, unconstrained input. Modern IDEs have tightened the loop, but the basic model is the same!
I am sure that error reporting will continue to improve along these lines, but here, I want to talk about a different model. Rather than starting with completely unconstrained input and having to decipher the inevitable parse and compile errors, let’s instead constrain the editing UI to only allow creation of programs that typecheck. I’ll call this the semantic editor model.
For example, if I would like to call the function
squareRoot (which accepts numbers), and I am filling in the argument, a semantic editor would somehow prevent me from providing the string
"hello!". This constraint raises some UX challenges:
squareRoot), the editor should provide some feedback–perhaps the autocomplete box has the goal type
Numberat the top, and the string
"hello!"is greyed out and unselectable, with its type (of
With a little thought and imagination, all these fun problems are solvable. Moreover, these are the sort of fun problems I want to solve, because a semantic editor is a much nicer user experience, and potentially a vastly more powerful environment than plain text editing. Here are just a few other advantages:
X, which differs from the type
Yof the value they’ve entered.
I’ll say more about how the challenges of a semantic editor are being addressed in Unison in a later post.
Update: See here for a very early demo of semantic program layout, and some further discussion.comments powered by Disqus