Fault unknown TAP tokens in strict mode (V13+)
Michael G Schwern
schwern at pobox.com
Sun Feb 17 23:05:27 UTC 2008
Andy Armstrong wrote:
> On 16 Feb 2008, at 17:43, Michael G Schwern wrote:
>>> +Returns true if the parser is operating in strict mode. Strict
>>> +is enabled when a TAP version number > 12 is seen. In strict mode
>>> +parser will flag parse errors for any unknown TAP tokens.
>> Whoa there! That's a major change. We should talk about it.
> OK. It's TAP 13 which was intended to be stricter. TAP 12 is unaffected.
I don't like the idea that specifying a TAP version means I'm going to have
trouble testing stuff that prints to STDOUT.
>> Historically, a TAP parser should ignore any unknown output for two
>> 1) It allows old parsers to still understand a subset of new TAP.
> I guess we could say that a TAP version N parser will be non-strict
> when it sees TAP version N+M
That's a good idea.
>> 2) It allows one to test things that print to STDOUT.
> Yup. Hmm. Dunno. That's always struck me as kinda dangerous :)
It's not by choice, I'll tell you that, but it is practical. You just don't
have that kind of control and being able to test anything trumps cleanliness.
It is the Test ANYTHING Protocol. We've lived with it for a long time now
and it only causes the very occasional glitch.
I have a feeling it's going to cause more trouble to be strict then it is to
just ignore it and it doesn't seem like there's a great clamoring for a strict
>> It doesn't solve #2. One often doesn't have control over the code
>> testing, so it makes that impossible.
>> At minimum I'd bump the TAP version #. And there needs to be a way
>> to shut it
>> off. Problem is, the test itself knows best whether there's going
>> to be
>> garbage on STDOUT. So the control would lie in the test.
> I quite like the idea of having to explicitly declare your test as
That would seem to introduce the idea of test pragmas which Eric seemed to be
I do have a cause though. It's obscenity. I'm for it.
- Tom Lehrer
More information about the tapx-dev