Here is what Jonathan has to write about his RakuAST grant progress:
Around half of the time that passed since my [last RakuAST grant report](https://news.perlfoundation.org/post/2020-07-grant-report-jnthn-rakuast) was spent on vacation, and an amount of it after that dealing with the fact that going on vacation doesn't mean the rest of the world stops finding things for you to do. Anyway, finally, in the last week, I got back into working on RakuAST again, and so have a little progress to report.
The biggest step forward was implementing basic support for `use`. This is the first `BEGIN`-time construct I've taken on, which meant some design work was needed. There are two cases to think about:
1. When we're parsing source code and building up an AST. In this case, the `use` statement can have an impact on how we parse the following code, and so we must perform the `BEGIN`-time effects of the `use` right away.
2. When we synthetically construct an AST. In this case, we're probably only doing the `use` in order to get its symbols. Thus the most natural place to perform the effects is during the first symbol resolution pass we make.
It's desirable that the two modes of operation can re-use the same code for performing the `BEGIN`-time effects, and the design I came up with seems to make a decent job of that.
This is one of the simplest cases of `BEGIN`-time; it does not require evaluating any code in the current compilation unit. That will not be the case in general, and some significant design effort will be needed there to get a good solution.
Before I ended up working on `use`, I was looking at package declarations, such as `class`. Figuring out how to deal with package symbol installation was giving me quite a headache; it's quite an imperative process and the resulting package structure does not much follow the AST structure. At some point, I realized that it could *also* be considered a `BEGIN`-time effect. I then switched to working on `use` - as described above - since it needed only a subset of the machinery that package handling will. With that in place, I'll soon be getting back to package declarations again.
My work towards package scope did yield some results, however. Of note, I provided a means for the parser to ask the resolver if a symbol corresponds to a type; this is used to distinguish the mention of a type (a term) vs. a listop routine call. With that in place, it was possible to compile things like `say Int` or `SomeGramamr.parse("blah")` using the RakuAST-based frontend.
While I was getting myself back into working on RakuAST, I also did a couple of simpler things: a basic implementation of the AST node for `start`, and rebasing the work onto the latest Rakudo master, so it works easily against HEAD versions of NQP and MoarVM.
One exciting thing about having basic `use` statement functionality in place is that `use Test` is also now possible from the RakuAST-based compiler frontend. This means it's possible to start attempting the spectest suite. So far it manages to completely pass 39 test files - a number that will probably climb quite steeply as some of the most common missing things get RakuAST nodes and are thus possible to compile. Just how steeply, we'll find out in next month's report.