Related articles |
---|
Re: A Simple EBNF Grammar based parser puneet@daffodilwoods.com (Puneet Agarwal) (2002-07-15) |
Re: A Simple EBNF Grammar based parser puneet@daffodilwoods.com (Puneet Agarwal) (2002-07-15) |
Re: A Simple EBNF Grammar based parser cfc@world.std.com (Chris F Clark) (2002-07-21) |
From: | "Puneet Agarwal" <puneet@daffodilwoods.com> |
Newsgroups: | comp.compilers,comp.compilers.tools.pccts |
Date: | 15 Jul 2002 23:56:30 -0400 |
Organization: | Daffodil Software |
References: | <agqaqr$npmh8$1@ID-99266.news.dfncis.de> <O87Y8.17900$jY5.409700640@newssvr21.news.prodigy.com> |
Keywords: | parse |
Posted-Date: | 15 Jul 2002 23:56:30 EDT |
Dear Brian,
Thanks for your reply.
> Most parser generators do more than generate a parser; they allow you to
> associate arbitrary semantic actions with parser productions. While it is
> quite straightforward to generate a parser that produces an AST from an
EBNF
> description, that's only part of what parser generators do.
It is easy to write down the logic for semantic testing in the classes that
are generated by my parser class generator. You can make out how much
semantic testing a Database Server needs to do. It is quiet easy to
implement that with my parser.
>
> First, not all parsing applications _want_ a syntax tree, or the
performance
> overhead that goes with producing one, or the memory requirements of
holding
> the whole parse tree in memory. Second, if they do want a syntax tree, it
> may not be exactly isomorphic to the input grammer. Third, they may wish
to
> make semantic parsing decisions based on information that has been parsed
> earlier, or generate error messages based on semantic data gathered from
the
> results of the state of the parse so far (such as type checking.)
I understand that not all applications need to generate synax trees. But
where it is required, it is a real big hassle to solve the problem of Left
Recursion. Isnt it?
Regards,
Puneet
Return to the
comp.compilers page.
Search the
comp.compilers archives again.