Re: Overcoming AST forward declaration (includes online example)

Michael Powell <[email protected]> Fri, 2 Nov 2018 18:56:50 -0400
Newsgroups gmane.comp.parsers.spirit.general
Message-ID <CAMEoF_HA6Z0+CpnLk0PgpJWwUPis-YDR55+gYR26Q3ajdn6hPw@mail.gmail.com>
On Fri, Nov 2, 2018 at 6:43 PM Larry Evans <[email protected]> wrote:
>
> On 11/2/18 4:33 PM, Michael Powell 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
> >
> Hi Michael,
>
> I briefly looked at the last link above and see you've noted in
> the comments on lines 233 and w258 here the forward declaration
> problems occur.  Also, there's still the large grammar alternative
> expression on line 429:

Sorry for the revisions. I'm trying to help that, so that we all can
focus on the question at hand best I can.

> Are you sure that wouldn't cause problems because the variant attribute
> for the rhs has the same type for each alternative?  Why not try just
> this as the sole rule in a vastly simplified grammar and see if qi
> will compile that.  Also, use the same idea to narrow down why the
> forward declarations are causing problems.  IOW, simplify your grammar
> to *only* cause the forward declaration problem and then show the result
> on another wandbox.org link.

I'm still not following you. What do you mean?

In this case, from my original code, the rule is this, synthesizing
type_t() in its namespace.

qi::rule<It, NS_PROTO_AST_H::type_t()> type;

Which does simplify just like you said:

struct type_t {
    std::variant<std::string, msg_type_t, enum_type_t> val;
    //                  ^^^^^^^^^
};

>    type %= (
>    // TODO: TBD: attempt at helping reduce the variant exhaustion a...
>      lexeme("double")
>    | lexeme("float")
>    | lexeme("int32")
>    // ...

That's exactly what the parens are for, whose alternate results all
reduce to std::string, correct? Whose overall result reduces to the
AST variant.

type %= (
        lexeme["double"]
        |  // ... Alternatives that reduce to std::string()
    )
    | msg_type
    | enum_type
    ;

> Yes, I know it's a lot more work, but it would *greatly simply the work
> needed by the readers of this mailing list in their attempts to help you
> and, by simplifying, you might discover the solution yourself!

Much of which is simply drawn from the Protobuf v2 specification on
its face. If there's a more elegant or better way to do that, I'm open
to suggestions.

https://developers.google.com/protocol-buffers/docs/reference/proto2-spec#fields

But this is not my block right now. My block is the MessageBlock
forward declaration, or, rather, how to solve that issue.

> HTH.
>
> -Larry
>
> by the readers of your posts
>
>
>
>
>
>
> _______________________________________________
> Spirit-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/spirit-general