On 13-04-25 08:37 AM, John Clements wrote:
FWIW, I'm (mildly) concerned too. In particular, I'm disappointed to discover
that in its present form (and using my present caveman-like invocation style),
ANTLR parses source files so slowly that it's impossible to use directly as a
validation tool; I would very much like to directly validate the grammar used
for documentation purposes against the existing sources. I haven't yet asked
for help from the ANTLR folks, because I don't yet feel like I've finished due
diligence on RTFMing ANTLR, which I would prefer to do before dumping the
problem in their lap.
I'm sorry for the confusion; I don't think patrick's work here
represents a divergence from yours so much as a continuation of it, in a
direction that answers a question I've asked repeatedly while you were
working on your grammar: "can we actually find an LL(1) factoring?".
Also "can any other non-antlr tools consume this grammar?"
Since you chose antlr4 rather than antlr3, the LL(1) question in
particular was obscured under the "antlr4 will parse anything!" sales
pitch[1]. Which is fine as far as getting the grammar roughed out and
running -- I'm not criticizing that decision, it was yours to make, as
was the choice of antlr in the first place. But it _did_ dodge a
question I've been quite persistent about asking; one which I wanted to
have an answer for before considering the grammar "done".
Longer term, I would like whatever grammar we wind up denoting as
canonical / documented / spec'ed to be as (re)target-able as possible.
I've been relatively insistent on LL(1) since it is a nice
intersection-of-inputs, practically guaranteed to parse under any
framework we retarget it to. IOW I do _not_ want to force anyone working
with rust grammars in the future to use antlr (3, 4, or anything else).
That's too tool-specific[2]. A grammar that is trivally translatable
between antlr4, antlr3, yapp2, llgen, llnextgen, coco, javacc, parsec,
spirit, "some rust parser-generator", and so forth is my "eventual" goal
here.
-Graydon
[1]: "We parse any grammar" is unfortunately common in parser-generator
sales pitches these days, with a profusion GLR and LL(*) things. As a
downstream consumer of parser-generator technology, let me point out
that while I appreciate broad guarantees by tool-makers, I very much
_dislike_ a tool that offers broad guarantees at the expense of being
able to make promises about efficiency, grammar class and algorithmic
complexity. IOW I actually prefer tools that can tell me what I need to
leave out (or change) in my grammar in order to arrive at an efficient
parser in a given complexity class. "Don't worry about it" is the wrong
answer here. I want to worry about it.
[2]: we also seem to be most-invested in python for in-tree
"maintainer-mode" tools associated with rust development; it seems like
a lot to ask to install a JDK in order to verify the grammar. If the
grammar-check _can_ be done in a python module, I'm happy to shift over
to using it. Unless antlr-ness is an important part of the grammar in
some way I'm not perceiving; do you have a strong preference for keeping
the java + antlr dependency?
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
