From: joel de guzman (djowel_at_[hidden])
Date: 2002-03-23 01:19:00
----- Original Message -----
From: "Douglas Gregor" :
> Knee-jerk reaction: will Spirit be bound to Phoenix? What I mean is, will I
> be able to use LL or bind to create Spirit semantic actions?
Yes. In as much as you can use an ordinary function or stl-style functor,
you can use LL or bind. However, without closures support, this will be
severely limited. The highly recursive nature of Spirit necessitates access
to true scoped local variables. Going back to our favorite example, the
= ureal_p[factor.val = arg1]
| '(' >> expr[factor.val = arg1] >> ')'
| ('-' >> factor[factor.val = -arg1])
| ('+' >> factor[factor.val = arg1])
= factor[term.val = arg1] >>
*( ('*' >> factor[term.val *= arg1])
| ('/' >> factor[term.val /= arg1])
= term[expr.val = arg1] >>
*( ('+' >> term[expr.val += arg1])
| ('-' >> term[expr.val -= arg1])
For those who do not know yet, the stuff inside the  brackets are the semantic
action functor. factor.val (for example) is a closure variable of factor. It is a
local variable that is instantiated once the factor rule is entered. Every invocation
of the rule factor instantiates a new set of local closure variables in the hardware
stack. This is the means for the parser to have synthetic/inherited attributes.
Right now, I have a decoupled reference implementation of closures. I wish
to adapt this to LL or possibly Bind. I think it can be done. I think such a
facility will be useful not only for parsing. If LL models an anonymous function,
the next logical thing is for it to have stack based local variables (and arguments).
The ref(x) facility simply won't cut it. In the viewpoint of the anonymous function,
the 'x' in ref(x) is a global (or static) variable. For instance, once a lambda or bind
function is named using boost::function, there is the possibility of recursion,
and thus the need for local variables.
> I'm always concerned with big libraries. It's hard for reviewers to give good
> feedback on a large library, and it would really help if Spirit were
> introduced and reviewed in pieces: e.g., core parser, multipass iterator,
> Phoenix all as separate _independent_ chunks. It's also much less to digest
> at once: a reviewer can pick up Spirit's parser syntax, but stay with a more
> familiar (to him or her) binding library for the actions.
Agreed. For that matter, I am trying hard to make Spirit modules independent.
Right now, Dan Nuffer has completed the full refactoring of the modules and
layers. The core layer for example is extremely small and can be used for
micro-parsing among other things.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk