Re: Fusion-ifying proto parse trees

Eric Niebler wrote:
> Joel de Guzman wrote:
>
> > One plausible way is to allow the client to declare/define the
> > overloads (through macros) in its own namespace with domain tags.
> > Then, the user can supply some domain specific customization
> > points for creating the data structures.
>
> If you go this route, you forfeit unification with Karma, xpressive, and 
> a host of other yet-to-be-developed parsing strategies. Instead, let's 
> make it trivial and efficient to get flattened views of the proto tree. 
> With the new proto/Fusion integration, we have a way forward. And once 
> Fusion supports segmented iteration, the whole issue becomes moot. That 
> is where we should be directing our energies, not in the Balkanization 
> of the proto data structures.

Certainly not. You can have all EBNF DSELs in a certain namespace.
For all those, a>>b>>c>>d is seq(a,b,c,d). Example:

    namespace boost { namespace ebnf
    {
        ebnf-operators-here
    }}

    namespace boost { namespace spirit { namespace classic
    {
        bool parse(...);
    }}}

    namespace boost { namespace spirit { namespace LL1
    {
        bool parse(...);
    }}}

The domain tag, in this case, is ebnf. spirit::classic and
spirit::LL1, plus all other parsing strategies share the same
operator sets.

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642