Eclipse Community Forums: TMF (Xtext)

Home » Modeling » TMF (Xtext) » Xtext and antlr4?(still no plans to use newer antlr?)

Fri, 24 January 2014 17:26

Eclipse User

Hello. It's well known that Xtext is fully dependent on antlr which is improving. I found this post made year ago: http://www.eclipse.org/forums/index.php/t/453013/
Are there still no plans to switch to newer and more powerfull versions of antlr?

[Updated on: Fri, 24 January 2014 17:27] by Moderator

Re: Xtext and antlr4? [message #1236508 is a reply to message #1235657]

Mon, 27 January 2014 06:24

Eclipse User

Switching to Antlr4 would be a breaking change, which means we'd have to
bump the version to Xtext 3.0 and would render all existing
implementations incompatible. Adding the fact that you cannot run two
different versions of the same Eclipse plug-in (e.g. Xtext) in the same
workspace on top should make it clear that such a move really needs to
pay off.

I had talked to Terence Parr (the Antlr-guy) right after he released
version 4 and asked him about the potential benefits. It turned out that
the automatic left factoring would be the main benefit. Performance
wouldn't be better he said (at that time). Also Xtext users wouldn't
benefit from the improvements in Antlr's API as they are shielded away
by Xtext's APIs anyway.

That was then, we could of course reopen that discussion again (in
bugzilla please) and see whether there are better reasons to do this
switch today. Maybe an option to choose the version would be the way to
go, such that don't need to break existing clients. But also that would
dependent on whether it is worth writing and maintaining an additional
parser generator.

Regards,
Sven

Am 24/01/14 23:26, schrieb Oleg Bolshakov:
> Hello. It's well known that Xtext is fully dependent on antlr which is
> improving. I found this post made in 2009:
> http://www.eclipse.org/forums/index.php/t/453013/
> Are there still no plans to switch to newer and more powerfull versions
> of antlr?

--
Need professional support for Xtext or other Eclipse Modeling technologies?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : http://blog.efftinge.de

Re: Xtext and antlr4? [message #1719614 is a reply to message #1236508]

Sat, 09 January 2016 20:14

Eclipse User

It seems that Antlr3 does not receive much support nowadays while ANTLR4. is updated on a regular basis. See also https://github.com/antlr/antlr3 vs. https://github.com/antlr/antlr4.

Have the plans regarding a version switch been changed in the meantime?

Re: Xtext and antlr4? [message #1745248 is a reply to message #1235657]

Thu, 06 October 2016 17:03

Eclipse User

ANTLR4 support is more and more critical. Should we re-consider switch to in some next release ?

Re: Xtext and antlr4? [message #1745259 is a reply to message #1235657]

Fri, 07 October 2016 01:51

Eclipse User

We can discuss / consider this at any time, for sure. We only need to compile a good list of reasons to do it. Currently I only see contra arguments, so please help explain why it is critical for you.

As I see it today:

Pro:
- claiming we run on Antlr 4 (which is actively supported by Terence and is perceived as the latest and greatest)

Against:
- Massively breaking change (requires major increment, which has a lot of bad effects especially for Eclipse clients. I.e. you cannot run Xtext 2.x and Xtext 3.x in the same IDE)
- Lots of work (we are talking months here)

IMHO the main benefit in Antlr 4 over Antlr 3 is the more user friendly API which is nothing Xtext users would benefit from, as we always had a user friendly API on top Smile

But please lets start a discussion and come up with reasons to do it or not to do it.

Sven

Re: Xtext and antlr4? [message #1745275 is a reply to message #1235657]

Fri, 07 October 2016 04:12

Eclipse User

Pro:
- benefitting from Antlr4's "Adaptive LL(*)" that allows to parse languages for which Antlr3 fails to compute the prediction DFAs.

Con:
- We loose static analysis. This means when generating the parser you will NOT get feeback about having an ambiguous grammar. Antlr3 can do this analysis but in Antlr4 this great feature fell victim to Adaptive LL(*). This is exactly the reason why we discourage using backtracking in Antlr3.

Re: Xtext and antlr4? [message #1759680 is a reply to message #1745275]

Sat, 15 April 2017 06:25

Eclipse User

Pro:
- Faster Parser Generation Times.
- Smaller code
- no need to post-process generated code due to "static initializer is exceeding the 65535 bytes limit" errors

Re: Xtext and antlr4? [message #1759681 is a reply to message #1759680]

Sat, 15 April 2017 06:44

Eclipse User

Hi

Pro: Arguably a SimRel contribution that is not able to use the latest version in Orbit is not current. Xtext should be antrl4 compatible.

Observation: The massively breaking change may not be that serious/it already exists.

Xtext (antlr 3.2), Epsilon (antlr 3.1b), ATL (antlr 3.0) are already incompatible. The conflicts only show up when two versions are used at once as I found when loading+parsing ATL, transforming to QVTrAS then serializing using Xtext to QVTr Text all in one JUnit test. Bang, conflicting Antlr versions.

So Xtext incompatibilities should only arise for users of two different Xtext variants in the same application.

As one of the more versatile SimRel contributions, Xtext's failure to support antlr4 inhibits others from using antrl4. Conversely if Xtext announces a move to antlr4, that will provide motivation to other projects.

Regards

Ed Willink

Re: Xtext and antlr4? [message #1759682 is a reply to message #1759681]

Fri, 14 April 2017 23:44

Eclipse User

well the point is: WHO should do this. i am currently basically alone when it comes to working on Xtext ...

Re: Xtext and antlr4? [message #1759773 is a reply to message #1759681]

Mon, 17 April 2017 23:38

Eclipse User

Ed Willink wrote on Sat, 15 April 2017 12:44

Observation: The massively breaking change may not be that serious/it already exists.

What are you talking about? Why would it not be serious and why does it already exist?

Ed Willink wrote on Sat, 15 April 2017 12:44

Xtext (antlr 3.2), Epsilon (antlr 3.1b), ATL (antlr 3.0) are already incompatible. The conflicts only show up when two versions are used at once as I found when loading+parsing ATL, transforming to QVTrAS then serializing using Xtext to QVTr Text all in one JUnit test. Bang, conflicting Antlr versions.

That is not what I meant. Bumping antlr to 4 in Xtext will not only have an effect on APIs but it will change the parsing behavior. So the same grammars will likely do different things, especially for broken files.

Ed Willink wrote on Sat, 15 April 2017 12:44

So Xtext incompatibilities should only arise for users of two different Xtext variants in the same application.

That is not possible anyway and unrelated to the question of upgrading the antlr dependency.

Ed Willink wrote on Sat, 15 April 2017 12:44

As one of the more versatile SimRel contributions, Xtext's failure to support antlr4 inhibits others from using antrl4.

Why?

Just to make it clear, I am not against this, but we should not play down the effects it will have for the better and worse. Also, it is a huge undertaking.

Sven

Previous Topic:	Cross Reference
Next Topic:	Xtext good pracitces

Goto Forum:

-=] Back to Top [=-

Current Time: Fri May 16 11:55:27 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter