TRPL

This crossed my way a couple a weeks ago and now I am feeling guilty that I did not make a post in time. But maybe it is not too late:

• The "DSL" part of the title is the one that triggered my thoughts on Groovy and Kotlin. Both are JVM languages that are close to Java in terms of paradigm (imperative, OO, etc. / but maybe a bit more oriented to scripting?). The point is that both got remarkable in terms of defining DSLs in.
• The syntax for higher order functions and affinity for functional programming makes a statement on their suitability to support DSL definition.
• A proof of concept for this is Gradle building tool (which FWD actually uses), that accepts both Groovy and Kotlin syntax. The FWD Gradle script uses a Groovy syntax, but at first sight, one can simply state that Gradle seems to be defining its building tasks in its own language - a DSL.
• I can agree that Scala's functional paradigm is more suitable to pattern matching (that fits parsers), but does it actually fit TRPL? I suppose the conversion rules can be interpreted as patterns that trigger actions in the conversion routine.

I wanted to bring this up because #1747 was posted 12 years ago (when kotlin was just born). I can't say the same on Groovy.
Let me know of your thoughts. IMHO, I have little experience with both Scala and Groovy/Kotlin, so from technical POV I would enjoy seeing TRPL supporting any of these :)

At one point (15? years ago now) I tested the performance of Groovy vs Java and found that Groovy was several orders of magnitude slower. I think that was at the same time that I was evaluating whether we could use Groovy as the target language for the converted code. At least at the time they did not have the ability to override the assignment operator so some of the most important operator override requirements were not met.

For TRPL, we have the requirement of overriding various operators but we also have other complex requirements. It is a good point about the pattern matching possibilities in Scala, which we may be able to leverage. My sense is also that Scala has a better performance profile than most other non-Java JVM-hosted languages.

To be clear, we can consider any of the JVM-hosted languages (not just Scala). I haven't looked at Kotlin but it has a good reputation. Whatever choice we make must be a well supported language. A big advantage of using a well supported language is to get get full source-level debugging for TRPL.

Greg Shah wrote:

Whatever choice we make must be a well supported language.

Java is still kinda supported, right?

Vladimir Tsichevski wrote:

Greg Shah wrote:

Whatever choice we make must be a well supported language.

Java is still kinda supported, right?

Java is fully supported as a language. But I'm not sure how that relates to this task. The idea of this task was to explore how an already-existing JVM hosted language could potentially replace TRPL. To do that we would need some language features that don't exist in Java, but some of which do exist in some of the JVM hosted languages like Scala.

Anyway, we aren't working on this task yet.