|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 (Jon Mauney)|
|Date:||Tue, 27 Apr 1993 03:43:47 GMT|
firstname.lastname@example.org (Simon Huntington) writes:
>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++ :-).
Can't let this go by without comment.
A) LL parsers can be as fast as anything else.
2) LL Parsers are to be *preferred* when repair is an issue.
The simple structure of the data on the stacks makes life
I'm not going to stick my neck out on III, however.
Jon Mauney email@example.com
Mauney Computer Consulting (919)828-8053
Return to the
Search the comp.compilers archives again.