Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do you plan to keep this codebase to be in sync with the antlr core? #14

Open
NorbertSandor opened this issue May 8, 2019 · 17 comments
Labels
question Further information is requested

Comments

@NorbertSandor
Copy link

Maybe it is easier than it seems at first sight? :)

@ftomassetti
Copy link
Member

Well, I do not think there is so much work going on on ANTLR core so I do not expect this to be hard.
Eventually I would like to get this merged into the main repository but before that is possible we need to improve the testing of this project

@ftomassetti ftomassetti added the question Further information is requested label May 8, 2019
@tim-patterson
Copy link
Contributor

Hi @ftomassetti I actually forked this from you last year some time.
It took a few tweaks for me to actually get it parsing and running my grammar correctly(ftomassetti/antlr-kotlin@master...tim-patterson:master).
And here's the grammar and tests I used with it - (https://github.com/tim-patterson/sql-parser) - reasonably complete sql parser.

While I think its a great idea having a kotlin runtime what I found is:

  1. The performance in javascript land wasn't great, the code was spending a huge amount of time in the kotlin js runtime doing "instanceof" checks.
  2. The current kotlin antlr code is based on an incomplete port of the java code with large parts still commented out - some of these turned out to be quite important and in some cases the converted code didn't quite follow the same semantics as the java code (esp around switch statements), both of these caused some quite hard to track down bugs....(not necessarily crashes just incorrect parsing)

While I'm very impressed that you managed to get this running I can't help but think that maybe the better approach here is to simply use the kotlin multiplatform expect/actual to build a common abstraction over the existing js and java runtimes thereby being able to take advantage of the existing runtimes that have been tuned and tweaked for their target platforms with the upshot that the maintenance burden would be much less.

I know you might be quite invested in your current approach and so this may not seem that constructive, for that I apologize.

Tim

@ftomassetti
Copy link
Member

Hi Tim,
sure more work is needed on this (I did not invest a huge time on this). However people are already using it and to some extent this works.

I have nothing against your approach, the only issue is: who has the time to implement this? Would you be willing to work on that?

I think we need for sure to generate Kotlin multi-platform code, so the wrapper would be just around the runtime. The generated code should be able to work with the multi-platform wrapper of the two runtimes. How hard would it be to generate code that works with that wrapper? I am not sure.

The current runtime is derived from the Java one, so I am not surprised it performs better on the JVM than on JavaScript

@NorbertSandor
Copy link
Author

Additionally, the current solution would probably work with Kotlin Native as well...

@ftomassetti
Copy link
Member

exactly @NorbertSandor , good point that I forgot about

@ftomassetti
Copy link
Member

By the way the key of having a multi-platform project for parsers is for me the possibility of building full multi-platform tools like compilers, interpreters, maybe even editors

@ftomassetti
Copy link
Member

BTW @tim-patterson it would be interesting to get some of your fixes merged back into this project

@ftomassetti
Copy link
Member

@tim-patterson I started looking into that but I could use some help #16

@KvanTTT
Copy link

KvanTTT commented Jan 9, 2022

Actually, I'm very interested in supporting it as an official ANTLR target since I'm working both on ANTLR and Kotlin 😃

Eventually I would like to get this merged into the main repository but before that is possible we need to improve the testing of this project

I think it makes sense to use official runtime tests that are used for all runtimes. I can help with porting a bit later when runtime infrastructure will be refactored.

@ftomassetti
Copy link
Member

Perfect, that would be great. Thank you for the offer

@lppedd
Copy link
Contributor

lppedd commented Dec 19, 2023

@KvanTTT fancy porting some useful grammars/runtime tests on this repo now that it's been upgraded? Would be cool 🔝

@KvanTTT
Copy link

KvanTTT commented Dec 19, 2023

Hi! Currently we've started discussion on developing of the next version of ANTLR, specifically the language we are going to use. I suggest Kotlin since it has a lot of benefits. That's why I will not invest effort for supporting Kotlin runtime for the ANTLR 4.

@lppedd
Copy link
Contributor

lppedd commented Dec 19, 2023

Sounds good @KvanTTT.
Do you already have a time frame for the next version? e.g., 2025 (even if it's your guess).

@KvanTTT
Copy link

KvanTTT commented Dec 19, 2023

Not yet, we are at the very beginning stage.

@lppedd
Copy link
Contributor

lppedd commented Dec 19, 2023

@KvanTTT reasonable. Is it possible to follow the discussion at some point?

@KvanTTT
Copy link

KvanTTT commented Dec 19, 2023

Not yet. But I'll contact the owner since I think public discussion could be more useful.

@ftomassetti
Copy link
Member

Not yet. But I'll contact the owner since I think public discussion could be more useful.

That is amazing! We love ANTLR and Kotlin, and we built some abstractions over ANTLR that we use in building our parsers. By the way, in the version under development we also take advantage of some interesting features of the K2 compiler :D
If at some point I can help providing feedback, or promoting what you are going to build, just let me know. It would be an honor to help in some way. Thank you for your amazing work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

5 participants