Lambda the Ultimate

I posted about my approach to this recently. The extended abstract linked above is light on details, but I mostly agree with the sentiment. The term "dialogue" sounds modal, so I don't really like that term. What should IMO happen is that as you type, the IDE labels ambiguity. If, after more context is supplied, the ambiguity remains, the programmer should be able to press a key to interactively select a resolution. In my system, that resolution just adds some code to the program text. That annotation is in a syntax that tells the IDE "don't show this", but if you looked at the source in a text editor, you'd still see it, so no special file format is required.

For me, the guiding principle behind this idea is that all ad hoc selection mechanisms should be resolved at edit time. That way establishing correctness of those complicated mechanisms can be done by inspection ("looks like the editor picked what I meant this time") without worrying about the general correctness of the selection algorithm. And the bit that's left to check with logical reasoning -- the run-time semantics -- is as simple as possible.

I've thought about such ideas before, albeit with my eyes on whiteboard meta-programming - having the IDE fill most of the gaps in the code or rough descriptions to sketch programs and prototypes in the period of an office meeting - rather than code proof. But I never found a satisfactory way to `save all the relevant context`. For my notion of meta-programming, that context was a collaborative search to eliminate ambiguities and meet constraints.

A big problem I had was the problem of further editing and refactoring of the code. It seemed difficult to reuse an old search after the editing. Further, it put a lot of burden on the editor - who might not be the original programmer, or might have forgotten enough to be a stranger to her own code.

This idea of annotating the code with specific references where collaboration and arguments are to occur, is enticing. It offers a structure I had not considered, something that might be leveraged to protect decisions (more relevantly, the arguments and justifications for and relationships between them) across edits.

I want their dealer's coordinates — I don't know what they are using, but this stuff is really good.

Or maybe I'm wrong. Maybe they just didn't try to compile somebody else's code. Ever.

There is a note in the abstract above that annotations resulting from the dialogue would be saved along with the code. So the author should have resolved the ambiguities while writing the code. If the code is only half finished then you face the same problems that you would when finishing off someone else's program: understanding where the holes are and what to fill them with. Edit: hit the wrong reply button, this was supposed to be a response to the post above by migmit.

Why stop at types?

I've been assisting (acting as a sounding board really) a speech researcher with a Siri-like dialogue systems lately. Basically, you parse utterances to (a) figure out the type of the command to be executed and (b) fill slots for the command. For any slot that needs to be bound unambiguously, the system can then ask a question to the programmer asking them to be clarify; it will also use your context (history, location, time of day, ...) to fill in slots if appropriate. As we've seen with Siri, this technology is sort of ready for use by consumers, not just the speech recognition component, but we (or at least Apple) seem to be breaking through on the dog-brain IQ needed to make a digital assistant useful in real life (also adding some EQ to improve the fun factor).

An utterance for one command is very different from writing a program. It is more like driving command-line shell or REPL. But if we think of these commands as instead mutating a single program at a very high-level, perhaps we could make some progress; think "the program is a game," "this stage has a maze," "when pac-man hits a ghost he dies." Hugo Liu and Lieberman's work on Metafor makes some progress in this direction, and is also very interactive (the shell will ask for feedback). Metafor will only generate a skeleton, so its not that useful, but we could imagine designing a programming language designed to allow programs to be expressed in this way.

This coding style sounds excellent. Worth noting is that practical IDEs already work this way, even if many language designers might not have considered it.

One question I have is why people feel the annotations should be some sort of side file or hidden annotation. Why not disambiguate the program and then reinsert the unambiguous version in the edit buffer?

Let me give two concrete examples where this appears to work well. First, in Java IDEs, you typically do not write down your import statements explicitly. Instead, you use unqualified names all over the place when you write the initial version of your code. At some point, the IDE does a compile, and it (non-modally!) indicates which parts of the code use an identifier that's not imported. The user can then interactively select which import to use. At that point, the import is inserted into the edit buffer, up at the top of the file. It's out of sight, but it's still ordinary text that will be saved in the file.

As another concrete example, Smalltalk programmers can go a long way without spelling identifiers all the way out. They just write the first few characters down. Eventually, they do a compile, and the system will ask--modally, I'm afraid--which identifier was really meant by each shorthand. After the user makes a selection in each case, the expanded identifier is inserted back into the code.

I don't see why it would be beneficial to hide the disambiguating information, and in fact it looks like a loss of clarity to people who later try to read the code. To draw an analogy, which way would you want spell checkers to work? Do you want them to leave badly spelled words in the text and put the correct word somewhere else, or should the replace the badly spelled word by the correct form?