Re: Introduction to Synopses
On 09/30/2013 02:16 AM, Patrick R. Michaud wrote: 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. It would be useful at some stage to come to a consensus about how to describe Perl6. 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. Larry Wall's ideas about language development differ from the paradigm that existed before. In one of the paradigms, a language designer creates a specification (eg. C) and then an implementation is created. This leads to the necessity for very tedious and specific specs. As pointed out in Synopsis 1, it implies perfect knowledge before the language has been created. What's new here is the three different components all moving together, and also that the language is defined in terms of both the specification and the tests. In the traditional sense, the specification of Perl6 is the combination of Synopses and Test Suite. But the Synopses on their own do not define Perl6, as you have pointed out. What I have suggested is to use another word describe (or perhaps define might be better) instead of specify. Specification has been used in the Perl6 community to mean the Synopses so I suggest keeping that identity. However, we use another word to describe the combination. 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. When is can a version of Perl6 be considered to have evolved? Rakudo is already being used to solve problems. I have used it to solve problems. Maybe not a vast range of problems, nor is the speed impressive. A language is in itself an abstract thing. Pm
Re: Introduction to Synopses
Hi Richard, On 09/29/2013 07:28 AM, Richard Hainsworth wrote: Some suggestions about documentation. Originally the Synopses were implementation oriented sumaries of the previous description base Apocalypses. That meant that the Synopses were derivative and secondary to the Apocalypses However, the Synopses are now primary specification and the Apocalypses have only historical significance. Also there are more Synopses than Apocalypses. I suggest the introductory paragraphs to the Synopses are changed to reflect this. A good idea. Please do it! The page you're probably think of is in the perl6/mu repo on github in the file docs/feather/syn_index.html. If you have a github user name, please tell me, and I can give you commit access. Cheers, Moritz
Re: Introduction to Synopses
On Sun, Sep 29, 2013 at 01:28:48PM +0800, Richard Hainsworth wrote: However, the Synopses are now primary specification and the Apocalypses have only historical significance. Also there are more Synopses than Apocalypses. One correction: The test suite (roast) is the primary specification (see Synopsis 1). To me, the Synopses are the English description of our understanding of the specification / language, as well as a roadmap for growth in the future. Pm
Re: Introduction to Synopses
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 I have seen elsewhere, can't remember where, that the parser written by Larry is also considered a part of the specification. Is this correct? From Synopsis 1: Perl 6 is anything that passes the official test suite hacking on any implementation of Perl 6 to make it conform to the test suite ... hacking on the test suite to make it reflect consensus of specification parts of the spec are already effectively frozen ...specced features ... not ... proven in an implementation ... considered ... conjectural May I suggest we add the following language to Synopsis 1 to capture all these statements? 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. The specification suite consists of the Synopses and the parser written in Perl6 A full implementation generates code that passes the entire test suite. 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. On 09/29/2013 09:13 PM, Patrick R. Michaud wrote: On Sun, Sep 29, 2013 at 01:28:48PM +0800, Richard Hainsworth wrote: However, the Synopses are now primary specification and the Apocalypses have only historical significance. Also there are more Synopses than Apocalypses. One correction: The test suite (roast) is the primary specification (see Synopsis 1). To me, the Synopses are the English description of our understanding of the specification / language, as well as a roadmap for growth in the future. Pm
Re: Introduction to Synopses
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
Introduction to Synopses
Some suggestions about documentation. Originally the Synopses were implementation oriented sumaries of the previous description base Apocalypses. That meant that the Synopses were derivative and secondary to the Apocalypses However, the Synopses are now primary specification and the Apocalypses have only historical significance. Also there are more Synopses than Apocalypses. I suggest the introductory paragraphs to the Synopses are changed to reflect this. It might also be useful to have a Synopsis 0 or Synopsis - index that documents the historical progression and indexes the Synopses. For completeness of language specification, Synopsis 0 could list the other documents that form a part of the language definition, such as the test suite.
