On 7/13/06, Jonathan Rockway <[EMAIL PROTECTED]> wrote:
> are you serious? listen to what they people here are saying - we _all_ > read the raw TAP output, all the time, and not because we're TAP > developers interested in the underlying implementations. as users, the > (current) raw TAP diagnostics helps us figure out why a test failed, and > if it doesn't make sense due to bad wording or reversed expectations > then it's that much harder than it needs to be. > No, you're reading diagnostic output that your program prints. "got" and "expected" aren't part of TAP, they're comments in the TAP stream that some emitters emit and that harnesses print. Look at the TAP grammer here: http://svn.perl.org/parrot/trunk/examples/pge/grammars/TAP.pg
wow, my code is being used in a flame war! *blush* :-)
There's no "got" or "expected" part of TAP, there's "ok 1" "not ok 3", "1..34", and "# this is a comment". So if we're going to add this to TAP, which I think is the whole point of this thread, then it doesn't matter what it's called. Your tap parser just needs to pick out a token, and throw a certain event if it finds that. It's up to the TAP harness (a level or so above the lexer/parser) to print "got: foo" "expected: foo". So if you don't like "got" or "expected", that's fine, just change the harness. I'm sure in some instances there won't be even be a line like that printed -- there will be a HTML table or something. That's the advantage of making these part of the TAP protocol; you won't have to worry about the semantics of "got" or "expected"... that will all be handled for you by the parser and then be presented nicely. To summarize, right now "got" and "expected" are artifacts of Test::More (etc.), not the TAP protocol.
the grammar file you referenced was the product of a short hacking session, and should not be billed as the official TAP grammar (i don't know if such a document even exists.) this thread has raised some good points, which you helped me organize here: it's important to consider the syntax, semantics, and pragmatics of TAP. after all, it is intended to be a use-anywhere test protocol (and i hope to implement it for parrot in a way such that any high-level language targeting parrot can easily use the same TAP library.) ~ Syntax: TAP 2 (or whatever it'll be called) must have a small, clearly specified grammar. this leads to better interoperation between TAP implementations, due to fewer syntax errors. this also leads to fewer semantic and pragmatic errors as well. ~ Semantics: TAP 2 must allow test module writers to express enough relevant information (through test descriptions, diagnostic output, tags, etc.) in order to describe a test result accurately--this includes custom diagnostic output specific to the problem domain. ~ Pragmatics: TAP 2 must allow users to understand all relevant information. if there's language or a method of presentation or other WTDI that is understood by a wider audience, it must be used over one understood by a smaller audience. i hope this categorization makes sense, and you find it helpful. ~jerry
