Language Design for IDEs

Picture of fabian-muehlboeck.md Fabian Muehlboeck

26 Sep 2024

Prerequisites

  • A good understanding of programming in a statically typed language.
  • It is useful if you have already taken a compilers course or have acquired a basic understanding of parsing elsewhere.
  • It would also be useful if you have a basic understanding of programming language theory.

For undergraduate projects, these latter two skills may also be picked up in the course of the project.

Motivation/Setting

Integrated Development Environments (IDEs) are a key part of modern programming ecosystems. Among other things, they provide programmers with live feedback about their programs and auto-complete suggestions. This requires them to “understand” partial programs, where large parts of the code may yet be missing. Effectively, IDEs use heuristics to guess what the completed program might look like, and from that derive the meanings of the parts that already exist. For example, the heuristic might decide that a particular identifier will refer to some class rather than a global variable, and therefore the IDE colors that identifier in the color used for class references, and writing a dot after it causes auto-completion suggestions to list the static members of that class.

For the purposes of this project, you may think of an IDE heuristic as a combination of an error-correcting parser (which may ignore parts of the code you wrote or fills out missing pieces to produce a parse tree close to what the language definition would prescribe) and a quite tolerant type-checker that allows for missing definitions or special “holes” in the parse tree produced by the above parser. Due to the complexity of coming up with good heuristics, only a few major languages have a good level of IDE support. There are ongoing research efforts to generate such heuristics automatically from a language definition, but in many cases, the way the language is defined makes this work harder than it should be.

Project Components

The project components listed here are part of an overall effort to explore principled ways of designing programming languages with good IDE support, as part of which I am developing a formal framework to judge the compatibility of language definitions with particular types of heuristics. The actual number and scope of components you need to do depends on the level of project you want to undertake (some of these can also be done by multiple people for different targets). I also am happy to chat with you about other ideas on how to improve the state of the art in this space.

  • Pick a (statically typed) language without major IDE support and implement a plugin for an existing editor (VS Code/Eclipse/…) to support this language, including type-checking (i.e. develop a particular heuristic).
  • Pick a statically typed language and develop a formal model of the semantics of partial programs in that language.
  • Prove properties about a combination of a particular heuristics and a formal model of the semantics of partial programs for a language.
  • Prove general properties about particular schemes of heuristics.
  • Survey existing approaches to IDE support in languages, with a focus on understanding as precisely as possible how any given (partial) program text is interpreted by the IDE
  • Develop an IDE-Plugin generator based on some notion of language specifications (PhD only)
arrow-left bars search times