Build a Q hierarchy/Q parser module for Perl 6

[masak]

Even in the 007 test suite, we have a couple of text-based tests that could be AST-based if only there were a good enough AST format for Perl 6.

I think it's time we drafted one. What would the extrapolation of 007's Qtypes look like for Perl 6? The closest thing that's been done here is trying to enumerate the Qtypes in Perl 6. My guess is that that list will need honing and fleshing out quite a bit.

The goal? Being able to parse (and having high confidence in mostly getting right) perl6-all-modules.

It would be nice of course if we could then turn around and use the Perl 6 Qtrees in our tests, to make them less text-based and sloppy. I'm thinking about these files, which all commit crimes akin to parsing (X)HTML with regex:

• t/code-style/do-not-call-made.t
• t/code-style/do-not-create-val-none.t
• t/code-style/do-not-use-str-in-typecheck.t
• t/code-style/taboo-words.t
• t/integration/finishblock.t (especially this one)

I only found a handful that actually are text-based, by necessity/nature:

• t/code-style/four-space-indent.t
• t/code-style/line-ending-ws.t
• t/code-style/no-commented-out-debug-code.t
• t/integration/meta-info.t

I'm thinking the work to parse Perl 6 and emit Qtrees should happen in a separate project, and be published as a module on http://modules.perl6.org — with luck, it could be seen as an early gift back from 007 to Perl 6, before Real Macros kick in.

I'm fine with closing this issue as soon as such a project/module exists.

[masak]

I'm fine with closing this issue as soon as such a project/module exists.

Though on second thought it makes much more sense to keep the issue open until the Perl 6 Q module is actually capable of supplanting the five identified tests. This also gives us a clear short-term goal.

[masak]

This effort should now definitely align itself with @jnthn's RakuAST effort.

[jnthn]

Seems it's really asking for an API to parse some source into its AST and then hand back the AST? (There was a recent suggestion of putting that functionality onto EVAL as a kind of "parse only", but that doesn't sit well with me, because the darn point is that we aren't going to be evaluating the code...BEGIN time aside!)

[masak]

I might be remembering a somewhat different issue (real or imagined). My main point is that it was created before the RakuAST effort started, and back then there wasn't really an "official AST format" for Raku, but that now there is. So at least that bit shouldn't be duplicated or needlessly diverge from RakuAST.