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

Replace ANTLR with pure-Python alternative? #445

Open
pp-mo opened this issue Sep 12, 2024 · 3 comments
Open

Replace ANTLR with pure-Python alternative? #445

pp-mo opened this issue Sep 12, 2024 · 3 comments

Comments

@pp-mo
Copy link
Member

pp-mo commented Sep 12, 2024

Relates to #423 - well, it would render that unnecessary I suppose.
Would perhaps be part of the solution to having a pure-python cf-units - see #446

@pelson
Copy link
Member

pelson commented Sep 13, 2024

The antlr runtime is pure python. Is the objective to be able to re-generate the parser with pure Python? This seems like a lot of work for not much benefit.

I see the fundamental concern with pinning to a specific version of antlr runtime - my guess is that we could support a version range, but I don't really know the compatibility guarantees of antlr. This will be the same problem for all users of the antlr runtime - perhaps we can follow the same approach used there (after all, ANTLR is popular).

@pelson
Copy link
Member

pelson commented Sep 13, 2024

FWIW the testing of the parser is extensive. I have confidence that if the tests pass, the runtime is fine. Perhaps then the antlr runtime can be bumped through dependabot frequently?

@pp-mo
Copy link
Member Author

pp-mo commented Sep 25, 2024

Is the objective to be able to re-generate the parser with pure Python? This seems like a lot of work for not much benefit.

Yes but, to be clear, our major driver for this is the ongoing cost of maintaining the extra-python components, i.e. Cython and the resulting complicated build and installation mechanisms.
And the majority of that cost, I would say, is not down to essential complexity of the work, but just because we lack the relevant expertise. Our experience in the current sprint certainly highlights that : apparently simple fixes are taking hours+hours of head-scratching, because we are all working with tools and techniques we don't understand in any depth.

There's a serious question here as to whether building our own solution could have similar problems, with tools such as a language parser being equally outside the experience of most of the team. But I'm hopeful that those parts would not change much and won't require much ongoing effort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Status: No status
Development

No branches or pull requests

2 participants