Conductor 1 uses a custom language implemented using ANTLR 4. The goal for Conductor 2 is to reuse an existing scripting engine.

Continuing with this, recently I started looking more closely at Lua to see if it could be a potential configuration language.

• Python
• Or Jython to be exact, which is already available in JMRI.
• Definitely a choice, but could lead to some fairly verbose declarations due to the lack of closures and such.
• Lua
• Luaj with JVM or Android support https://github.com/luaj/luaj
• Class binding via https://github.com/luaj/luaj#luajava.
• Simple language, clear semantic, very “traditional”, no magic, lotta parentheses.
• Actually has closures.
• ⇒ Not better than Python for that task.
• Kotlin
• The original choice I had in mind.
• Do not like the hype around the language (no, it does not magically make apps better or faster).
• Not a big fan of some of the weird syntax choices.
• Requires DSL classes to be implemented in Kotlin.
• Groovy
• Current choice.
• Not fundamentally different from the syntax available by Kotlin.
• Does not require DSL classes to be implemented in Groovy. Can use POJO.
• Easy to understand, got quick satisfying results with minimal effort.
• Certain limitations due to the “a b c d ⇒ a(b).c(d)” fixed parsing.
• Local variables (explicitly defined by a “var”) are not exported.
• Some IDE support with IJ (didn’t seem to understand custom classes though).

So the goal is so far to try with Groovy.

Step 1 is to write a mock Groovy file that would map the current automation, and “add” something that is not possible in the current flow.

The part that must be validated is how to deal with closures/lambdas for actions.