Xsemantics is unmaintainable

[SimonCockx]

Over the last couple of months, our Xsemantics file defining the type system of Rosetta has grown significantly (1000+ lines of code). This has resulted in a serious burden on Eclipse while developing the type system - practically freezing the whole IDE for a couple of seconds on every edit when the Xsemantics file is open. From this, it has become clear that Xsemantics might not be suitable (yet) for larger projects such as this one.

I propose to convert our type system into a pure Java implementation, and to remove our dependency on Xsemantics.

[cdietrich]

did you test if splitting the rules over a file hierarchy helps?

[SimonCockx]

@cdietrich I haven't yet. That's a fair suggestion before I condemn the current state of Xsemantics. Thanks

[SimonCockx]

In PR https://github.com/REGnosys/rosetta-dsl/pull/538, I split my code in three:

• auxiliary methods that don't rely on judgements
• the implementation of my judgements
• all checkrules

where each system extends the previous one. This results in files no more than 540 lines. While it did help in decreasing the waiting time, I'm still disturbed by the amount of time I have to wait while editing something, especially because I foresee another significant growth in file size in the future. Splitting into more would either lead to arbitrary grouping of rules, or to an overly fragmented type system, so I still think that for this particular project moving to a pure Java implementation is beneficial.

[LorenzoBettini]

@SimonCockx For sure, your type system is pretty big, and splitting it might help.

Were the other Xtext DSLs you worked without problems in size based on Xbase? I think the bottleneck in Xsemantics is how it resolves and checks call to judgments because it searches the resource for judgments with specific symbols. I guess a better solution would be to annotate generated Java methods (e.g., with arguments about the symbols used) and then let the Xsemantics compiler search into the Jvm type model for annotated methods instead of traversing the resource. However, I cannot tell in advance whether this would improve performance. In any case, this means a huge refactoring in Xsemantics, which I cannot deal with right now.

If you think you don't get any benefit from Xsemantics, I'd be the first one to say you should switch to a pure Java implementation of the type system (of course, this means re-implement everything also concerning error reporting or traces). You'll have full control of it but also full responsibility ;) I'd also tend to say that while this will give you easy and efficient Java editing (for sure, nothing will beat the JDT editor), you'll have to take care of the runtime efficiency of your type system.

Final note: you're using Xsemantics 1.22 with Xtext 2.27. They're both quite old. I released Xsemantics 1.23 a few days ago with Xtext 2.30.

[SimonCockx]

Hi @LorenzoBettini, thanks for the analysis, that's quite interesting.

Were the other Xtext DSLs you worked without problems in size based on Xbase? I think the bottleneck in Xsemantics is how it resolves and checks call to judgments because it searches the resource for judgments with specific symbols.

I had a suspicion this might be more related to Xbase than to Xsemantics. One of the DSLs I was referring to is, of course, Rosetta itself, for which Eclipse never showed problems back in the days when we still supported Eclipse. We don't use Xbase.

If you think you don't get any benefit from Xsemantics, I'd be the first one to say you should switch to a pure Java implementation of the type system (of course, this means re-implement everything also concerning error reporting or traces). You'll have full control of it but also full responsibility ;)

I would never say I don't get any benefit from it - I love the tool, and were I given the time, I would gladly help improving it. Having used it this much, I often get ideas for improvements, as some of the issues on the Xsemantics GitHub page illustrate. :)

We have in the past talked about contributing some of our time to improve Xtext - something which I still intend to follow-up on. I might as well include Xsemantics for that matter.

I'd also tend to say that while this will give you easy and efficient Java editing (for sure, nothing will beat the JDT editor), you'll have to take care of the runtime efficiency of your type system.

Interesting. Would you say that a naive translation to Java would be insufficient efficiency-wise, if you had to make a guess?

Final note: you're using Xsemantics 1.22 with Xtext 2.27. They're both quite old. I released Xsemantics 1.23 a few days ago with Xtext 2.30.

Xtext 2.27 is from May 2022 - I wouldn't call that quite old yet. ;) In the past, upgrading from Xtext 2.25 to 2.27 proved to be really painful - mostly because of breaking changes in the Xtext language server. We had to spent about 3 weeks of developer time just to get everything working. That's the main reason we're hesitant when it comes to upgrading Xtext and related dependencies such as Xsemantics. Our current approach is not to upgrade Xtext unless warranted by an actual use case. I'm not sure if this is a good approach, or whether we're just postponing the inevitable.

[LorenzoBettini]

@SimonCockx , I guess you might experience performance problems also with a huge Xcore file, though I guess Xcore might be more optimized in some respects than Xsemantics.

Concerning the naive translation to Java, it depends: a type system is a complex beast (looks at the Xbase type system implementation). I'm just saying that re-implementing a type system from scratch is a complex task, especially related to error reporting and its workflow, not to mention optimizations in some specific parts (though caching through Xtext caching mechanisms might be enough; Xsemantics caching is based on Xtext mechanisms for caching).

Concerning upgrading: Generally, a project should have a solid test suite. Given that, upgrading libraries and frameworks should be a breeze (upgrading Xsemantics from 2.27 to 2.30 was just a matter of changing versions and verifying that all tests are still passing, thus, about an hour but only a few minutes of man work). For sure, the more you wait to upgrade, the worst it will be ;) Moreover, if you don't upgrade, you won't benefit from bug fixes and improvements. IMHO, in terms of software, May 2022 is an eternity ago ;)