Related articles |
---|
[3 earlier articles] |
Re: A minimal LL(1) parser generator ? carlglassberg@gmail.com (2019-12-29) |
Re: A minimal LL(1) parser generator ? gaztoast@gmail.com (2019-12-31) |
Re: A minimal LL(1) parser generator ? anton@mips.complang.tuwien.ac.at (2019-12-31) |
Re: A minimal LL(1) parser generator ? carlglassberg@gmail.com (2020-01-01) |
Re: A minimal LL(1) parser generator ? gaztoast@gmail.com (honey crisis) (2020-01-02) |
Re: A minimal LL(1) parser generator ? anton@mips.complang.tuwien.ac.at (2020-01-02) |
Re: A minimal LL(1) parser generator ? gneuner2@comcast.net (George Neuner) (2020-01-02) |
Re: A minimal LL(1) parser generator ? rockbrentwood@gmail.com (2020-01-04) |
Re: A minimal LL(1) parser generator ? gaztoast@gmail.com (honey crisis) (2020-01-05) |
Re: A minimal LL(1) parser generator ? carlglassberg@gmail.com (2020-01-05) |
Re: A minimal LL(1) parser generator ? carlglassberg@gmail.com (2020-01-05) |
Re: A minimal LL(1) parser generator ? carlglassberg@gmail.com (2020-01-05) |
Re: A minimal LL(1) parser generator ? anton@mips.complang.tuwien.ac.at (2020-01-22) |
[4 later articles] |
From: | George Neuner <gneuner2@comcast.net> |
Newsgroups: | comp.compilers |
Date: | Thu, 02 Jan 2020 13:16:52 -0500 |
Organization: | A noiseless patient Spider |
References: | 19-12-016 |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="11415"; mail-complaints-to="abuse@iecc.com" |
Keywords: | LL(1) |
Posted-Date: | 02 Jan 2020 13:22:19 EST |
A little late to the discussion, but ...
On Sat, 21 Dec 2019 19:07:55 -0800 (PST), Andy
<borucki.andrzej@gmail.com> wrote:
>ANTLR has even LL(*) but is too complicated. I am searching maximal
>simple and elegant generator which generates function call like
>written by hand.
There are a number of decent tools that will generate recursive
descent code, but you won't find any that will produce code as tight
as custom hand written.
You neglected to mention what programming language you want to target.
However:
PCCTS is the ancestor of ANTLR. It is LL(k) for configurable k. It
produces C or C++ code for the parser. You need to supply a lexer
separately.
Coco/R is LL(k). There are versions available for several languages,
including C, C++, Java, Delphi, VB, etc. Like ANTLR, Coco/R also can
generate a lexer.
In my experience, PCCTS produces tighter code than ANTLR. As long as
you don't need the flexibility of LL(*) - or need a lexer generated,
or to target a language other than C or C++ - then PCCTS may be the
better choice.
If you need one stop shopping for RD coded parsers and lexers, then
you do need something like ANTLR or Coco/R which can do both.
>Temporary goal: must be very simple, because this will not parse
>program/document, just only strings with my definitions of (augmented)
>regular expressions. I can write it by hand, but generator minimizes
>possibility making mistake and systemztize work.
If you are working with individual strings rather than a multi-string
"document", then perhaps you really only want a lexer generator.
Perhaps something like RE2C which takes regex patterns and generates
code (in C) to recognize them. The recognizers are FA, but the code
is generated inline in the function that needs it.
Or boost::spirit, perhaps in combination with boost::regex (or
std::regex in C++11 or later). Spirit has a fairly steep learning
curve also, but it has the advantage that it requires only the C++
compiler and does not need a separate tool.
Hope this helps,
George
Return to the
comp.compilers page.
Search the
comp.compilers archives again.