[TransWarp] fmtparse - recursive grammar

[Oleg Broytmann]

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 
> automatically.
> 
> 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.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.