Need a high-level API #4713
Replies: 6 comments 2 replies
-
|
I’ve argued against this elsewhere. We’re inviting trouble if we’re make it any simpler to start using it I think. On Oct 4, 2024, at 11:48, Blake McBride ***@***.***> wrote:
While working with the latest ANTLR, I've come to the following opinion: ANTLR provides a very powerful and functional toolkit. However, a higher-level API is sorely needed (without getting rid of the toolkit API). A great deal of, effectively, boilerplate code could be combined to make this higher-level API. It would make ANTLR far, far easier to use.
Some examples:
Why treat the lexer and parser as two different entities throughout when they're interrelated? Treat them as a unit.
Except for testing, why would anyone want errors printed to the console? Put them in a linked list and then provide a simple utility to dump them to the console when testing rather than the other way around.
Many, many more instances of stuff like this exist. You could easily create a high-level API that would make using ANTLR trivial rather than a pretty complex project.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I agree! We wouldn't want more people using ANTLR! I assure you, it is possible to create a drastically simpler interface without losing any functionality! |
Beta Was this translation helpful? Give feedback.
-
|
I think you missed my point, facetious comment not really appreciatedOn Oct 5, 2024, at 14:47, Blake McBride ***@***.***> wrote:
I agree. We wouldn't want more people using ANTLR!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
APIs are like flavors of ice cream. People like different things, and sometimes what you like changes from time to time. The question is: Does the API have all that it needs to parse input, output a parse tree, errors, and diagnostics to debug your grammar? Does it have enough to support the testing of itself? Yes. People are always going to want some new "flavor." For example, the parse tree printer ToStringTree() outputs an s-expression. But you can't tell what token type a token is from the output, where the token begins and ends. And there is no "indented-style" tree output API, where each node in the tree is a separate line. Are the newlines in that string Unix-, Windows-, or old Mac-style? Why bother outputting open and close parentheses if every tree node is on a separate line and is indented depending on depth? If you want a different API, write a layer that does what you need. I personally needed to make Antlr parse trees editable, the XPath engine something more up-to-date and in-line with the XPath standard, and output not only a serialization of the parse tree but of the parser and lexer. And, there was so, so much more. This is why I wrote a toolkit around Antlr. |
Beta Was this translation helpful? Give feedback.
-
|
My car has a drivetrain and a braking system. They're pretty independent, but I drive my car as a unit. It's not a matter of the flavor of the ice cream. It's a choice between buying an ice cream cone OR getting the ingredients and creating the ice cream, the cone, and then putting it all together. Why make each person create their own ice cream factory? You do not have to lose any functionality. You build the easy-to-use API on top of the existing API. The existing layer remains available. In my 40 years of experience building frameworks and APIs, I assure you: A. ANTLR is a fantastic and useful tool! The needless complexity of ANTLR's API is the #1 reason it's not used a hell of a lot more. B. A far, far simpler API could be built. The way to do this is to build a couple of primary use case examples and then factor out the common code unrelated to the specifics of the problem (the particular grammar). Put that common code in a new API. Do this for several different use cases. Eventually, doing common things becomes very easy. Since you didn't touch the lower-level API, you didn't reduce any existing functionality or mess up existing applications. Lastly, if you take a look at my GitHub account, you will understand why I can't take this project on. I'm just sharing an opinion based on many years of experience. I am done with the topic. Do as you please. |
Beta Was this translation helpful? Give feedback.
-
|
Please note: I am not an admin in this repo or the grammars-v4 repo. Of the few changes that I made here, they had to be approved by those in charge. And, no matter my degrees, my ~40 years in writing compilers and software development, none of it has led to any seniority or respect. The Issues List is filled with many good ideas that won't get implemented. And, for a number of good reasons. So, I do what I can do, with the tools that are available--which are excellent. The only thing I would have to say about Antlr is that it is very, very hard to write a good grammar, even for language designers and tool writers. (~150 of the ~350 grammars in grammars-v4 are ambiguous. antlr/grammars-v4#4276.) My hat is off to all who try. |
Beta Was this translation helpful? Give feedback.
-
You say this based upon what evidence though? In 20 odd years, I have not seen many people talk about this (I may just not remember). Of course, it is possible that people give up and don't tell us why. But generally people give up because they can't grok how the grammars are put together, not because they don't get the API. I am willing to listen, but I cannot really see how there would be a significant gain in understanding by creating some higher level API to be honest, nor can I really envision what that API would be. Perhaps I am too close to the existing API/ |
Beta Was this translation helpful? Give feedback.
-
|
I was not suggesting that you be the one to make these additions. I know it won't be me. It just occurred to me that the opinions I was sharing do not appear to be common, or after all of the time ANTLR has been around, something would have been done. I agree that what Parr has done is fantastic and well appreciated. (I actually met him ~25 years ago.) I also agree that creating a correct grammar is challenging. (There may be some interesting work for ANTLR to provide an analysis of a grammar and help point out problems.) I suppose opinions, even by those with a lot of experience, are of no value. And actual work is rarely appreciated either. Good day. |
Beta Was this translation helpful? Give feedback.
-
ANTLR provides a very powerful and functional toolkit. However, a higher-level API is sorely needed (without getting rid of the toolkit API). A great deal of, effectively, boilerplate code could be combined to make this higher-level API. It would make ANTLR far, far easier to use.
Some examples:
Why treat the lexer and parser as two different entities throughout when they're interrelated? Treat them as a unit. (You can still get to the individual parts through a unit API.)
Except for testing, why would anyone want errors printed to the console? Put them in a linked list and then provide a simple utility to dump them to the console when testing rather than the other way around.
Many, many more instances of stuff like this exist. You could easily create a high-level API that would make using ANTLR trivial rather than a pretty complex project.
Make this high-level API handle common use cases in very few lines of code and then give access for the ability to do more complex things.
I should be able to call a single method that could validate an input text and return a linked list of errors.
Beta Was this translation helpful? Give feedback.
All reactions