Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| EBNF conflict avoidance slk12@earthlink.net (SLK Parsers) (2002-11-20) |
| Re: EBNF conflict avoidance clint@0lsen.net (Clint Olsen) (2002-11-24) |
| Re: EBNF conflict avoidance slk12@earthlink.net (SLK Parsers) (2002-12-11) |
| Re: EBNF conflict avoidance clint@0lsen.net (Clint Olsen) (2002-12-13) |
| Re: EBNF conflict avoidance slk12@earthlink.net (SLK Parsers) (2002-12-19) |
| From: | "SLK Parsers" <slk12@earthlink.net> |
| Newsgroups: | comp.compilers |
| Date: | 19 Dec 2002 12:43:39 -0500 |
| Organization: | Parsers Inc. |
| References: | 02-11-118 02-11-134 02-12-073 02-12-081 |
| Keywords: | parse |
| Posted-Date: | 19 Dec 2002 12:43:39 EST |
> So, I would actually approach it from the standpoint of providing an
> init-block and then and action block in the event the rule is matched.
The roughly equivalent EBNF is
list -> _action_initialize { item _action_item } _action_finalize
which in BNF is
list :
_action_initialize item_01_*
item_01_* :
item _action_item item_01_*
_action_finalize _epsilon_
So the init action really does not need special handling by the
parser-generator. Its placement is natural, whereas the finalize action
needs to be handled differently from the item action. In many cases, no
action is needed for the null production. The idea of having two separate
actions is to fully reflect the structure of the underlying BNF grammar. See
http://parsers.org/slk/example.html for a simple EBNF expression grammar
with actions.
http://parsers.org/slk
Return to the
comp.compilers page.
Search the
comp.compilers archives again.