Spin off grammar to its own module

[JJ]

Which will help leverage it for other harnesses

[jonathanstowe]

Works for me.

[Leont]

I don't see how that would help. You may misunderstanding how the module works if you think you need that part specifically (which is probably my fault because it's severely under-documented), you will need quite a lot of other stuff, so much so that spinning off pieces is probably not the easy solution.

Could you please take a step back and describe what problem you're trying to fix is?

[Leont]

Simply put, I have a hard time imagining a problem where the solution isn't using TAP::Harness, though I can easily imagine one wants to use a non-standard Reporter (the current one is based on the perl one and I'm entirely open to replacing it with something better anyway).

And if I'm wrong then that probably means TAP::Harness should be improved instead.

[JJ]

First, there are not enough grammars in the ecosystem. Having grammars out there would help improve the visibility of this feature, and encourage people to create their own ones.
Second, TAP::Harness is excellent, but it certainly has several different parts that are loosely coupled. That's exactly as it should be, but that precisely makes spinning off the grammar easier. Right now it's not even exported, having a private scope, which makes difficult to reuse.
Third, small modules are easier to maintain and evolve than big ones.
And fourth, as stated, it would encourage people writing different test runners, with different capabilities, bells and whistles.
Finally, I'm only talking about the grammar itself, not the actions. That's something specific to the module, and totally different.

[Leont]

First, there are not enough grammars in the ecosystem. Having grammars out there would help improve the visibility of this feature, and encourage people to create their own ones.

But it is already out there?

Second, TAP::Harness is excellent, but it certainly has several different parts that are loosely coupled. That's exactly as it should be, but that precisely makes spinning off the grammar easier.

Agreed.

Right now it's not even exported, having a private scope, which makes difficult to reuse.

That's mainly because the current shape isn't very suitable export. TAP is both streaming and multi-line, and therefore it needs the preprocessing in sub parser to make sense of a stream, but that's currently kind of tied the Action and the Entries. Though I suppose that isn't necessary if one is matching the whole TAP document in one go.

Third, small modules are easier to maintain and evolve than big ones.

That doesn't mean that pretending a big module is actually a few small modules make it easier to maintain or evolve; it can easily become more complicated in fact because suddenly dependency issues come into play.

And fourth, as stated, it would encourage people writing different test runners, with different capabilities, bells and whistles.

Why would people want to write different test runners? What kind of different capabilities, bells and whistles do you imagine? I mean I have a few things on my TODO list, but I can't imagine anything that one would want that isn't on that list.

I see plenty of reasons to write alternatives to the porcelain of prove6, but why would you want to reinvent the plumbing ? What's the benefit of that?

Finally, I'm only talking about the grammar itself, not the actions. That's something specific to the module, and totally different.

Fair enough.

[Leont]

I've just released a new version of TAP, including two changes that should make reuse of the module easier:

• TAP::Grammar is now public, and has a TOP that matches a whole TAP stream.
• I've added some helpers so now you can do something like:

  my TAP::Result $result = await TAP::SourceHandler::Raku.make-parser($filename, :@include-dirs);
  

  This should make it easier to run a test without the orchestration of a TAP::Harness