-
Notifications
You must be signed in to change notification settings - Fork 47
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
Comments
Well, I do not think there is so much work going on on ANTLR core so I do not expect this to be hard. |
Hi @ftomassetti I actually forked this from you last year some time. While I think its a great idea having a kotlin runtime what I found is:
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 |
Hi Tim, 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 |
Additionally, the current solution would probably work with Kotlin Native as well... |
exactly @NorbertSandor , good point that I forgot about |
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 |
BTW @tim-patterson it would be interesting to get some of your fixes merged back into this project |
@tim-patterson I started looking into that but I could use some help #16 |
Actually, I'm very interested in supporting it as an official ANTLR target since I'm working both on ANTLR and Kotlin 😃
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. |
Perfect, that would be great. Thank you for the offer |
@KvanTTT fancy porting some useful grammars/runtime tests on this repo now that it's been upgraded? Would be cool 🔝 |
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. |
Sounds good @KvanTTT. |
Not yet, we are at the very beginning stage. |
@KvanTTT reasonable. Is it possible to follow the discussion at some point? |
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 |
Maybe it is easier than it seems at first sight? :)
The text was updated successfully, but these errors were encountered: