|predicate parsing firstname.lastname@example.org (Ariel Meir Tamches) (1993-04-21)|
|Re: predicate parsing email@example.com (1993-04-22)|
|predicate parsing firstname.lastname@example.org (Stephen J Bevan) (1993-04-22)|
|Re: predicate parsing email@example.com (1993-04-23)|
|Re: predicate parsing firstname.lastname@example.org (1993-04-23)|
|Re: predicate parsing email@example.com (1993-04-27)|
|Re: predicate parsing firstname.lastname@example.org (1993-04-28)|
|predicate parsing email@example.com (Trevor Jenkins) (1993-04-28)|
|Re: predicate parsing firstname.lastname@example.org (1993-04-29)|
|Re: predicate parsing email@example.com (1993-04-29)|
|Re: predicate parsing firstname.lastname@example.org (1993-04-30)|
|From:||email@example.com (Simon Huntington)|
|Organization:||SoftWare Interrupt Developments|
|Date:||Fri, 23 Apr 1993 15:27:51 GMT|
Re regarding predicate parsing:
What exactly are predicates? I've had a look at the *excellent* PCCTS
which uses predicates, but I don't see how they can help very much. I'm
trying to write a C++ parser (something simple to start with :-)), but
predicate parsing would have to look-ahead many tokens to decipher
ambiguities wouldn't it?
I wrote a backtracking LALR parser which basically recursively 'trial'
parses (similar method to Gary Merrill, but trial parsing is specified
with the grammar). I've managed to get it to parse almost all C++,
including templates and exceptions, but it's pretty big (>950states). I
also needed error repair which is why I **had** to write my own parser.
I'd have liked to use LL since it is much easier to understand but seemed
to run into so many problems. Firstly, I wanted it to be as fast as
possible. I can write the parser driver in assembler to read the tables.
Second, I needed error repair. LL parsers seem to have a hard-time
repairing errors. Thirdly, I couldn't parse-out those lovely ambiguities
in C++ :-).
.. So, would predicates help or what? Are they for simpler things?
Software Interrupt Developments, Leeds, UK.
Return to the
Search the comp.compilers archives again.