[TransWarp] fmtparse - recursive grammar
phd at work.phd.pp.ru
Mon Jun 16 07:16:52 EDT 2003
On Fri, Jun 13, 2003 at 04:11:26PM -0400, Phillip J. Eby wrote:
> The only reason this doesn't work the way you'd want it to, is that the
> Sequence tries to adapt 'subqueries' to a Rule immediately, which won't
> work because Query doesn't exist yet. If the adaptation were delayed, I
> think this would actually create the needed circular references
> So, what we really need here is to change 'fmtparse' to do its adapt()
> calls on demand at a later stage, instead of up-front. Converting to Once
> bindings would be ideal for this, although I originally intended fmtparse
> to be a standalone demo of what kinds of things can be accomplished with
> PEP 246 adapt(). Guess I'll have to give up on that.
> Perhaps you could contribute a patch to change fmtparse to use Once
> bindings for all adapt() on input arguments? E.g. Alternatives() would
> save its args in initArgs or _alternatives, and then have .alternatives be
> a Once binding that adapts, instead of __init__ doing the adapting. There
> are only about 5-6 places that need changing for this, I think.
My first attempt was unsuccsessful. There is _computeRules() and
openingChars in Sequence; I tryied to make _computeRules a delayed function
(I renamed it to rules() and made it binding.Once)... and there is the
problem - _computeRules() calls getOpening() on subrules, so openingChars
must be defined in the subrules; but one of the subrules is actually
recursivly referenced rule, that did not defined openingChars yet - it will
be defined in the end of _computeRules(). Catch 22. Calling self.rules in
getOpening() produces infinite recursion, od course.
How can I calculate openingChars in non-recursive way?
Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
More information about the PEAK