Builders provide the final result of a chain of language processing steps to the language user, hiding the actual language processing steps such as parsing, analysis, and transformation from the language user. The Spoofax API for builders requires only a couple of lines to invoke a builder and access its results. This changes, once the input to the builder are not only source files of the object language. When we want to configure a builder, for example based on flags passed to a command-line tool or based on a configuration file for a tool which invokes Spoofax, we need to perform language processing steps manually again:: Parse, analyse, create Stratego term for compiler options, invoke strategy on analysed AST combined with options AST.

The Spoofax API could support extra build parameters, which could be passed as term arguments to the build strategy. This definitely requires a separation of builders and menu entries (there is an issue for this already), since these builders could not easily be associated with a menu entry. The menu entry would either need to provide values for the build parameters (in the ESV file) or allow for user input (either interactively or by user configuration).

Submitted by Guido Wachsmuth on 7 March 2017 at 06:24

If you abstract over these kind of problems a bit more, it comes down to a problem of configuring a language on multiple levels. For example, a language product such as Java 8 has several global configuration parameters, such as its home location (JAVA_HOME), its version, default JVM arguments, and so forth. The user is able to override some of these parameters, such as the JVM arguments, when running the JVM. In an IDE such as Eclipse, there is also a lot of Java editor configuration such as syntax highlighting colors, formatting options, all with defaults and the possibility for the user to override them.

Some configuration options apply to projects, such as the classpath, while others are specific to a builder, such as where the Java compiler should output its class files, and of what version those class files should be.

In general, I think we need a layered configuration system which can be used to configure:

• (Meta-)Language products
  • Global configuration
  • Editor services
  • Builders
  • …
• The language workbench itself (meta-configuration)

on different levels:

• Globally (defaults)
• Per workspace
• Per project
• Per file
• Per builder

We also don’t want to limit ourselves to just builders defined in Stratego. We should support definition of builders in Java, Scala, Stratego, and other languages as well. That requires a separation of the builder specification (interface) from the implementation. It also requires conversion of the configuration arguments to a format that the implementation language understands.

Finally, the entry points of builders should indeed not be limited to ‘menus’. Builder specifications should be separated from entry points such as:

• Global menu
• Context menu on:
  • Projects
  • Files
  • Editors
  • Elements inside an editor
• Keyboard shortcuts
• Events
• …

To summarize: we should support configuration of language products on multiple levels, and we should separate builder entry points, from builder specifications, and builder implementations.

This seems to be the right level of abstraction to think about a number of issues and features. Great proposal, Gabriël.