Re: Down to three tools...

I too made a great search for parser/compiler generator tools. I also
checked out PRECC, which I found to be pretty impressive but poorly
documented. All the features of PCCTS, but hard to "guess" how to get
started.


You may want to consider PRECC as your fourth candidate. It is at:


            http://www.comlab.ox.ac.uk/archive/redo/precc.html
    or http://163.1.27.90/archive/redo/precc.html


Now, about the other three candidates (I really only know about 2 of
them):


> INPACT5 inpact5 <inpact5@clr34el.der.edf.fr> wrote in article
96-07-048...
> <H2>Presentation of the problem :</H2>
> <H2>A few comments on these tools :</H2>
> <H2>pccts :</H2>
> Appears to be everything that I've ever wanted a translator to be. I
> only need to define a couple of files and away we go. So, where's the
> documentation? I have the book. It reads like a reference manual. The
> guide for newbies seems pretty cryptic (I need to know how to use pccts
> to understand the guide... ack!). I want to know how to _use_ the
> language! The tutorials are in C mode - which is great and all, but I'd
> like to use C++ mode. No, I don't learn really well just in looking at
> the examples - and besides that the examples do not appear to pertain to
> my case. All I want to do is to put the thing in an AST and then into C
> - how hard can it be? I've already got a great start on my grammar
> (thanks to Pat Terry - see coco/r). Is there a reason why no one
> answers my requests for the pccts Pascal grammar? Should I just mail
> directly to John with all of my questions? (I know that I wouldn't want
> my mailbox cluttered up with silly questions, but you guys sure aren't
> helping all that much!)


PCCTS is now my tool of choice for a few reasons:


- The EBNF can be quite readable if you do it right.
- Inifinite lookahead... or 1, 2, 3, ... levels of lookahead. You can
pass the
    lookahead value in as a parameter to the parser generator.
- The Lexical and Parser stuff all lives in a single file together, and
their
    descriptions are so tightly integrated you don't really have to know
where
    one ends and the other begins. Although if you've used Lex & Yacc it
    should be pretty obvious.
- It is oh so portable, I've compiled the generated code everywhere. With
the
    exception of Visual C++, it works great. Visual C++ seemed to choke on
    large grammars. Microsoft's official reply: "the parser will not handle
more
    than 103 nested levels of if/then/else/for statements". Something to do
with
    a known "feature" of their preprocessor. Otherwise works great on every
    ANSI-C compiler I've tried.
- Grammer maintainability is outstanding, as compared to tools like YACC.
    I even forgot how to say "shift-reduce conflict".
- All can be done in one *.g file, or in multiple files if you so desire.
Very
    compact grammars make this do-able. If you want multiple *.g files and
    supporting *.c files you can do that as well.
- You can also override the default error reporting quite easily -- which
was a
    must for my application.
- The command line is straightforward, and works. I didn't have to use
ANY
    graphical tools, which I like. That way I can build the antlr/dlg
commands into
    my Borland IDE, Microsoft Visual C++ IDE, or a Unix makefile. No sweat,
    and no buttons to push during the build process.
- Has been thoroughly tested and supported. PCCTS is a mature product.
- A C++ parser has been written using PCCTS. This to me is the acid test
of
    power of a parser, as C++ is 'bout the nastiest language there is to
have to
    parse.
- I could understand and debug the generated code. My superiors
particularly
    liked this fact, as I can pretty much assure them that I'll never be
backed in
    a corner because some "black box" that isn't even my software broke.
Remember
    Lex & Yacc and those huge tables of numbers. Not my cuppa tea.


I too was intimidated by the documents, but after I implemented my sample
grammar in PRECC, PCCTS, YACC, and a few other tools (some commercial!),
PCCTS won hands-down for usability, maintainability, readability, and all
those other
...ilities. I think it's the best compiler generator I've ever seen...
and I've used several.


I printed all the documents, including the release notes for each
version (these can be VERY VERY helpful!!). I had about 3" of papers
when I was done. The documents I used the most are the introduction
to PCCTS, the newbies section, and the book.


Of course I have not used the C++ stuff, I only used C. Seems that
many folks have had success with the C++ generator as well. One tip
to remember with PCCTS is that you might need to look at the generated
code (which is surprisingly readable) to get some clues where the
documentation is vague. I have had to do this a couple of times,
especially when overriding the error reporting features.


>
> <H2>eli:</H2>
> Way cool. Appears to be everything that I've ever wanted a translater
> to be (where have I heard this before?). Um. How do I use it? The
> documentation is profuse but not very helpful. The graphic interface is
> cool but annoying (shouldn't I be able to use the little arrow to go to
> the next page?). The examples don't compile! (Ok, I got some of them
> working with help from Basim Kadhim and Matthias Jung - thanks guys!)
> And good grief, but it sure looks like you need to define a hell of a
> lot of files (sub-parts? sub-grammars? Oh, little bits...) to get it
> to run - and the syntax is really confusing (on the semi-compiled bits -
> when it's all in separate files it's reasonable but you sure have a lot
> of those little files) - and the interface (the non graphic part) uses a
> really cryptic syntax - and I'm pretty sure that I don't understand how
> to apply it to my situation (though it is euqally sure that the right
> tool exists for the job, I just don't see exactly how to use it).


Eli is cool, yes. But it is huge. I read and read and read... and
then I read some more. I never got a good enough grasp to get around
to trying to use it. From what I could gather, Eli is a whole set of
tools. The goal of the entire system seems to be the ability to
specify the input you want to recognize and the resulting output, and
leave out the "how" part. It seems you can get away without having to
specify anything so formal as a Lex parser description or even a
BNF-style grammar. Then Eli fills in the blanks and builds a parser,
AST building, and AST walker to recognize your input and generate an
output. This is of course my meager understanding. I'm no expert on
Eli.


Seemed like the swiss army knife of parser tools, but I just gave up
after a few hours of reading.


>
> <H2>coco/r:</H2>
> I have yet to determine if it is everything that I've ever wanted a
> translator to be, but the grammar is really easy to use and very
> understandable. Pat Terry has been a great help with all of my
> problems. The docs haven't been completely updated since the last
> version (a major change) so I don't really know how to use it to do
> what I want to do or even if it will do it (or if I'm going to get
> stuck dealing with a symbol-table and similar - nasty and undesirable -
> stuff myself).


Not familiar with this one. I looked at a README on it once, but I think
I wrote COCO off since it didn't seem to have infinite lookahead. Maybe
COCO/R does, I just don't know.


> It doesn't seem like I should have to know more than I do now (as far as
> compilers go I've only just finished up this year with my first course
> in language theory) to make this work


here, here...
I agree. It should be simple enough to translate your ideas about your
language syntax into a working parser. Debugging a grammar can be
difficult enough sometimes, without also having to learn a complicated
parsing tool. That's what I liked about PCCTS. You can make it as
simple or complicated as you want, and you aren't forced to use even
1/10th of the capabilities of the system (or even know how to use
Sorcerer) to do most things. Of course if you do have a complex
grammar, the capability is there.


--

Return to the comp.compilers page.
Search the comp.compilers archives again.