Re: Overcoming AST forward declaration (includes online example)

Michael Powell <[email protected]> Fri, 2 Nov 2018 18:34:02 -0400
Newsgroups gmane.comp.parsers.spirit.general
Message-ID <CAMEoF_ECtoY_DUCys4424s+6B-2gKWfwJcupvyu9zkmhzaxVRw@mail.gmail.com>
On Fri, Nov 2, 2018 at 5:33 PM Michael Powell <[email protected]> wrote:
>
> On Fri, Nov 2, 2018 at 10:18 AM Michael Powell <[email protected]> wrote:
> >
> > Hello,
> >
> > Please find the example posted here:
> >
> > http://wandbox.org/permlink/NI2Luvrw1HF7lF1E
>
> I resolved a couple of obvious typos, so what remains I think are the
> forward declaration concerns:
>
> https://wandbox.org/permlink/tM6vQilplqDOL4v5

The forward declaration errors now the top most errors:

https://wandbox.org/permlink/WeRqkmDR93Wqu8BI

> > The couple of concerns I have in question at the moment are:
> >
> > * How to best handle variants throughout the grammar. Can I use
> > std::variant? Do I need to use boost::variant? Are there additional
> > Spirit features that make this doable?
> >
> > * Embedded in that question is what to do with "nil" or "empty
> > statements" which occurs throughout the grammar at times. I wondered
> > if "empty statement" could synthesize "nothing", literally, not
> > contribute to a variant alternative, for instance. Other AST examples
> > seemed to inject a "struct nil {}" pattern, so I figured maybe this
> > was the better approach?
> >
> > * The real kerfuffle for me at the moment is the AST forward
> > declaration. From what I gather in the protocol, this is an absolute
> > must have. It most occur before Group, and is also used by Message.
> >
> > Thoughts? Suggestions?
> >
> > And, please, before you suggest there are "proto compilers" already
> > available: yes, I know, I've been down that road. I am not looking to
> > parse the proto itself, per se, but rather do some code generation for
> > target language artifacts other than the proto itself.
> >
> > Toward which end, I am also investigating a protoc compiler plugin
> > approach. But I figured, I'd pursue this as a  viable path to solving
> > the problem as well, notwithstanding the above challenges.
> >
> > Thanks in advance!
> >
> > Cheers,
> >
> > Michael Powell