On Mon, Sep 30, 2013 at 02:03:43AM +0800, Richard Hainsworth wrote: > Not wising to disagree with PM, but "|docs/feather/syn_index.html" > states on line 1:| > "The Synopsis documents are to be taken as the formal specification > for Perl 6 implementations"
What follows is just my opinion, there's plenty of room for reasonable disagreement. Over the last couple of years I've come to disagree with this statement in syn_index.html . Informally we often talk about the synopses as being "the official spec", and I'm as guilty of that as anyone else. Even the name of the repository holding the synopses is given as "specs". But as all of us know, some parts of the synopses are incredibly slushy, or even quite fluid, and so it's not something that people can really treat as truly "specification". And there are countless parts of the synopses that have radically changed as a result of lessons learned in implementation... (I can tell long stories about S05!). Thus it was recognized early on (in Synopsis 1) that acceptance tests provide a far more objective measure of specification conformance than an English description. There are likely things that need to be "spec" that cannot be fully captured by testing... but I still believe that the test suite should be paramount. > Perl6 language development is a gradual change of specification, > test suite and implementation until the specification is proven by > implementations, which all pass the test suite, for some sense of > 'proven' and some set of 'implementations'. > > A "version" of Perl6 is "described" by the combination of a > "specification suite" and a "test suite". I'd prefer that versions of Perl 6 be captured solely by the test suite. I don't know how practical this is, though. I don't like the notion of "specification suite"... it feels too nebulous to me. > A version of Perl6 is declared to be ready when there is at least > one full implementation exists that generates code considered to be > sufficiently fast and memory efficient. I also don't like the idea of defining "readiness" in the abstract. Something is "ready" when it is capable of solving the problem(s) to which it is being put. Pm
