"Joseph F. Ryan" <[EMAIL PROTECTED]> wrote in message news:3DD0674C.1080708@;osu.edu... > A module? For something as basic as print? > I hope not, that would certainly be a pain.
My understanding is that C<print> will be a method on C<IO::stream> (or whatever), which has a default invocant of $stdout. This module might be included automatically, so users don't need to know about it. Anyway, calling C<print> "basic" is a very biased point of view. Its the viewpoint of someone who knows how things are implemented. > >If 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). > > > > I think the point that Sean was trying to make was that for some kind test > 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. I think it would be a mistake to assume that we can't use a testing infrastructure for tests. Sure, there need to be some implementation-centric unit tests that depend on almost nothing: but those tests should be run as a guard around a main regression (i.e. a regression script should say "do clean checkout; run sanity checks; if OK, then run regression"). If C<perl6 -e 'assert 1'> fails, then things are broken. It is also a mistake to base the decision on the fact that perl is currently too slow. This will be fixed: performance of dispatch will be crucial all perl scripts, not just tests. > >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). > > 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. This feels like a false augment (even if the conclusions are true). Contrast: C<assert> takes a single arg, and evaluates it in boolean context. It if the result is false, then execution terminates. OTOH, C<print> takes a list of args; iterates through them, and calls a polymorphic (in parrot) method on each. If I make a primitive assert op in parrot, then the perl implementation is rather basic. assert_equal is a bit more complex. But the complexity can be structured. We don't need, initially, to implement heterogeneous comparisons, for example. At a more detailed level: a test that compares integers doesn't need strcmp to work. You seem to be concerned about a boot-strapping problem. I want to make the assumption that there is a level of functionality below which it is pointless to run user-level tests. Dave.
