[960] Fault unknown TAP tokens in strict mode (V13+)

Eric Wilhelm scratchcomputing at gmail.com
Sun Feb 17 18:55:56 UTC 2008


# from Andy Armstrong
# on Sunday 17 February 2008 09:39:

>On 16 Feb 2008, at 18:15, Eric Wilhelm wrote:
>> All new tap would have a known prefix?  That is, a v13+ parser
>> should be
>> able to say "that is a TAP keyword, but I don't support it."
>
>Kind of restrictive, no?

Yeah.  Your suggestion of just disabling strict if $version > $supported 
is probably the way to go.

>> I like the idea of TAP being stricter, but I'm not sure if it is
>> warranted or desirable.
>
>I can't parse that :) Why do you like it then?

uncertainty ne dislike ;-)

The benefit of stricture is less ambiguity.  The drawback is that (1) 
cross-version and (2) intra-tool version compatibility is more 
difficult.

If we only enable stricture for known versions, then (1) is solved 
(solved in terms of stricture -- actual forward version compatibility 
depends on a lot of things.)

Without some kind of prefix in front of all tap, (2) requires the 
emitter to exert itself a bit more if any garbage is to be passed thru 
(e.g. tie STDOUT or something.)  It could declare e.g. 'v13 strict' at 
the beginning, but needs to then have begin/end garbage directives and 
e.g. print_garbage() functions.  This will, of course, also have the 
same issues as xml CDATA in that the end directive could appear in the 
output.

But, CORE::GLOBAL::print is non-replaceable, so a nice DWIM 
implementation in the emitter isn't going to be easy, right?  Given 
that the call to print could happen anywhere, I guess the use-cases are 
going to be either "strict on" or "strict off".  So, that simplifies 
the implementation to just a declaration in the header?

Unfortunately, making Test::More default to strict will break CPAN, and 
typing "use Test::More strict => 'no_plan'" will be tedious, so I would 
like a Test::Smore. :-D

--Eric
-- 
But you can never get 3n from n, ever, and if you think you can, please
email me the stock ticker of your company so I can short it.
--Joel Spolsky
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------


More information about the tapx-dev mailing list