Patrick R. Michaud wrote:
On Tue, Sep 02, 2008 at 02:10:39PM +0200, Moritz Lenz wrote:
And then? Spec it? Or ship a prototype as "official"?

I think it's good to have a prototype that we can point to as
a reference, but I don't think we need to try to designate it as being

I think we *should* have an official, but that it should be conceptualized in a slightly different way. Or actually I have 2 alternate proposals:

1. Rather than being a "language extension", should formally be part of the Perl 6 test suite itself, as the result of a refactoring; basically all tests have some common implementation parts and those have been refactored into a module, which is So then is an integral part of the test suite itself, and if there is just one official test suite, then there is just an official Though for convenience this would be installable so that other language extensions could use it in their tests, though.

2. The Perl 6 language spec itself would specify a basic set of test routines built-in to the language, in a Test namespace, much as it defines collections of routines now for such as numbers and arrays and standard I/O. And so the basic test routines would be formally defined in a Synopsis document. This shouldn't be onerous as there'd probably be only about a dozen such routines and given our experience it is probably reasonable they won't need to change much over time. So how these Test namespace routines are provided can then vary by the implementation but they would be standard to users of the language.

Now a common factor to both of my proposals is that this is intentionally kept as simple as possible and contains just the functionality needed to bootstrap the official Perl 6 test suite; if the official test suite doesn't use certain features, then they don't exist in this, in general.

There would still be room for third party Test modules, as those would be richer and provide functionality that would be useful for testing language extensions / CPAN modules but that aren't needed by the tests for Perl 6 itself.

I should mention that I'm currently pursuing the #2 approach in my Muldis D language design, where the language spec itself includes a small number of common routines implementing the TAP protocol over standard I/O, so that tests written in the language can just use it without having to explicitly load a Test library like a user-defined library.

An advantage of #2 is that you don't have to think so much about what other language features your uses, since from the users' point of view they are themselves fundamental features; so implementers could even bootstrap them using native equivalents or a prelude.

I also don't see the possibility of our "getting it wrong" in the design to be such a big deal, since the odds are anything we think of now will work well for many years, as has been fairly stable already and meanwhile Perl 6 is versioned now, so we could make an incompatible change to the Test related language spec in the future, and as long as users say "use Perl-6.0.0" their code relying on the older/current like interface won't break.

-- Darren Duncan

Reply via email to