[TransWarp] fmtparse - recursive grammar

[Phillip J. Eby]

At 06:10 AM 6/21/03 +0300, alexander smishlajev wrote:

>>and second, rules don't know about their containers.
>
>that's where Input could help.  the last rule that called input.parse is 
>the container for current rule.

But the sibling that determines the terminators may not be a child of the 
same parent rule.


>>I don't think you can transfer the necessary knowledge to the Input 
>>without making it part of the parsing state, which will make the system 
>>much slower.
>
>i did not intend to transfer the knowledge to Input.  i want the input 
>object to act as a proxy to the container of the rule.
>
>a new method is added to containing rules: getTerminatorsFor(rule).  in 
>Sequence, this shall scan the following siblings of the rule, calling 
>getOpening() on each of them, starting from the very right.  Optional, 
>Repeat and Alternatives should just return their own terminators (computed 
>at the start of their parse).

Well, I don't know if your suggestion would work, but I found a simpler way 
to fix the issue, and have checked it in.


>still, i think that state should be a special object rather than plain 
>integer, to allow graceful error reporting as described in chapter 3.2.4. 
>of the Bryan's thesis.

You can do this using most of the framework as-is, as long as you replace 
the '*String*' classes with your own implementations.  (That is, you just 
need replacements for StringInput, MatchString, StringConstant, and 
ExtractString.)  The other classes don't make any assumptions about what 
'state' is, as long as it's not a ParseError.  I did it this way on 
purpose, so that most of the code is reusable.  Only rules that deal in 
concrete matching or extraction of data need to understand the input and 
parse state, and the input only needs to be able to supply a "start" state, 
and to be able to tell if a particular state means parsing is complete.