Re: [boost] Re: [ANN] Spirit C++ parser framework.

From: joel de guzman (joel_at_[hidden])
Date: 2001-05-23 21:32:08

----- Original Message -----
From: "Larry Evans" <jcampbell3_at_[hidden]>:

> There's a link on my webpage at
http://sites.netscape.net/cppljevansusa/homepage to
> a ps description of a similar idea, but it creates a comiler for LL(1)
grammars.
> All the productions were placed in a container of some sort and each
non-terminal had
> a FIRST and FOLLOW and NULLIBLE member variable.  So, one problem with
> maintaining SPIRIT as is but allowing more efficient implementation  would
be that there
> would have to be a parallel heirarchy of classes augmented with these
member variables
> or attributes.  Anyway, the above ps description has most or all of the
source code; so,
> it may be a starting point for this "compile" idea.  However, it wasn't
in-place.  It generated
> c++ code for the compiler.  To make this in-place would involve some sort
of
> internal rep for c++ classes which could then be interpreted by some
"virtual compiler?"
> Or am I misunderstanding what you mean by "in-place"?
>

I tend to agree with Vladimir Prus. I quote: "I think that if some automata
building library is available, it can be easily accomplished. However,
such a library should be completely independent one."

I feel I should separate the "automata building" front-end from the parser
generator back-end. This would allow multiple back ends to be easily
integrated without the overhead of the "default" or "reference
implementation" if you will, which is the one Spirit is using now. Being
able to choose a back-end would be, to say the very least, awesome.

I have a general idea on how this could be done. I guess, I will need closer
collaboration with you guys to make the back-end interface right. I imagine
an intermediate template-meta-program.

Have a nice day...
Joel de Guzman