|Using Bison and Delphi firstname.lastname@example.org (Mike Hahn) (2004-11-17)|
|Re: Using Bison and Delphi email@example.com (2004-11-19)|
|Re: Using Bison and Delphi firstname.lastname@example.org (Mike Hahn) (2004-11-20)|
|Re: Using Bison and Delphi email@example.com (2004-11-26)|
|Re: Using Bison and Delphi firstname.lastname@example.org (2004-11-28)|
|Re: Using Bison and Delphi email@example.com (Jeremy Wright) (2004-11-28)|
|Re: Using Bison and Delphi firstname.lastname@example.org (Mike Hahn) (2004-12-05)|
|Re: Using Bison and Delphi email@example.com (John R. Strohm) (2004-12-06)|
|Date:||19 Nov 2004 00:53:27 -0500|
|Organization:||AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com|
|Posted-Date:||19 Nov 2004 00:53:27 EST|
"Mike Hahn" <firstname.lastname@example.org> schreibt:
>I would like to know if it's a good idea to use Bison to generate the
>parser, and then translate Bison's output, either using some tool or
>by hand, into Object Pascal. I am a complete newbie when it comes to
Perhaps you should try CoCo/R for your parser, to get Pascal code
immediately. Since CoCo creates recursive descent parsers, you can
step through the created code when debugging your grammar. Bottom-up
parsers (automatons) are not so easy to debug - if ever. At least I
recommend that you start with a recursive descent parser, to collect
some experience before you go on with bottom-up parsers.
BTW there exist Lex/Yacc (Flex/Bison) ports to Pascal, like tply41a
(Turbo Pascal) or dyacclex (Delphi).
The omission of punctuation between identifiers (dot operator,
argument list separator...) may cause more trouble than it's worth -
worth what at all? Since all tokens (identifiers...) must be separated
somehow, it doesn't make a big difference whether the separation
character is a space, dot, comma or whatsoever. Distinct separation
characters, instead of only whitespace, also allow for easier parsing
(less lookahead) and better diagnostics and error recovery.
Return to the
Search the comp.compilers archives again.