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

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.


Reply via email to