Dave Whipp wrote:
"Sean O'Rourke" <[EMAIL PROTECTED]> wrote in message > One thing the
"golden-output" has going for it is that it gets into and
out of perl6 as quickly as possible. In other words, it relies on
perl6/parrot to do just about the minimum required of it, then passes
verification off to outside tools (e.g. perl5). I realize they can be
fragile, but at least for the moment, we can't rely on a complete
perl6 Test::Foo infrastructure, and I think that in general, we
_shouldn't_ require such a thing for the very basic tests. Because if we
do, and something basic is broken, all the tests will break because of it,
making the bug-hunter's job much more difficult.
I see where you are coming from ... but is the IO infrastructure really the most primitive thing to rely on? It may be at the moment; but I expect that it will become more complex. C<print> may be a built-in right now; but it should probably move to a module later.
A module? For something as basic as print? I hope not, that would certainly be a pain.
I think the point that Sean was trying to make was that for some kind testIf we can't rely on C<assert(0)> to kill a test (and C<assert(1) not to>; then things are pretty badly broken (assuming that C<assert> exists).
infrastructre to be available to Perl 6 to test Perl 6 with, it would have
to be implemented in Perl6 first. The problems with this are:
1.) Perl 6 at the moment is *extremely* slow. This has much to do with
the huge grammar PRD has to handle, but why make the testing any slower
than it already is?
2.) If there is a problem with some part of the compiler that the testing
mechanism was built with, it will break the testing mechanism. This will
needlessly break all of the tests, and could be very painful to debug.
If we are going to pick a very small subset on which almost all tests will depend ... isn't it better to pick the test-infrastructure itself to be that dependency; rather that some arbitrary module (like IO). Dave.
Well, the P6C print implementation is as basic as it gets; all it does is take a list of arguments, loop through them, and call parrot's print op on them. Although the full implementation will be more complex (as it will have to handle printing to filehandles other than stdout), the testing implementation won't have to deal with that. However, assert is bound to be more complex, since it will have to handle and compare many different types of data structures.