TL;DR Imo, one of Perl 6's notable strengths is its approach to its specification. Imo companies will love it. I can see it becoming a primary tool for driving P6 forward in just the right way.
---- Steve has already answered with the short version of some of what I say below, and I agree with what you (Darren) said in your reply to him. So perhaps this is more for ToddAndMargo or other readers. >From the start in 2000, Larry intended that the P6 project would distinguish between various distinct notions of "specification": * An evolving set of English documents that would be used to guide compiler developers attempting to write a compiler that implements that "specification". For the last few years P6 project leaders have been calling these "Design Documents". The latest/last versions of these are stored at design.perl6.org. They are now largely an historical footnote -- calling these or any other English language documents a "specification" was explicitly deprecated some years ago. * An evolving set of English documents that would be used to guide end users attempting to understand or write P6 code. Aka end user documentation. The latest version of this is stored at doc.perl6.org. Contributors can draw insight from the design documents (as per previous bullet point) but are supposed to focus on the only remaining specification (as per the next bullet point). * An evolving Executable specification that emerges from that effort. A compiler **must** match **100%** of this executable specification if the compiler is to be officially allowed to claim it implements that specification. This is what the 6.c specification is and what the 6.d specification will be. * The 6.c specification is stored at https://github.com/perl6/roast/tree/6.c (Maybe we should change the description from "Perl 6 test suite" to "Perl 6 language specification".) There's also a 6.c errata at https://github.com/perl6/roast/tree/6.c-errata which, aiui, is what the monthly Rakudo releases target. So, anything you read in English, like "doesn't yet implement macros" is... written in English and is not part of a Perl 6 language specification, per contemporary P6 usage of the word "specification". > So I think it is reasonable for Rakudo to actually implement ALL of 6.c > before too long, that it would catch up, and otherwise the intent is that > Rakudo would be leading on things that eventually become 6.d etc later. Aiui Rakudo's HEAD implemented all of 6.c (on at least one platform) as of December 25th 2015 and each subsequent monthly release has as well. (Well, actually, all of 6.c.errata.) In principle this is an excellent foundation for manageable (in tech and business senses), systematic, community driven, compiler dev mediated, language stability, backwards compatibility, and evolution. If someone (or some company) wants to drive the language forward, then they work with the community to propose changes to the test suite for 6.d or some later 6.* version. These changes test that the particular features they want are working. Community members can do things like attaching a time-limited incentive for compiler devs to alter the compiler to pass some particular set of new tests. Indeed, I imagine it would be fairly easy to set up a flow of direct micro-funding of whatever a given community participant considers more important to them. If it's backwards compatibility, then write tests that ensure that backwards compatibility if they haven't already been written and/or add incentives to currently failing/skipped tests. A similar approach applies for those wanting more test coverage of existing features, or new features. -- raiph On Tue, Jul 25, 2017 at 11:23 AM, Darren Duncan <dar...@darrenduncan.net> wrote: > There's a key difference however. > > While programming languages continue to evolve, the expectation is that a > production-complete Rakudo would always be a functional superset (or equal > to) the Perl 6 language specification which is current at the time. > > So I think it is reasonable for Rakudo to actually implement ALL of 6.c > before too long, that it would catch up, and otherwise the intent is that > Rakudo would be leading on things that eventually become 6.d etc later. > > The original question would be more accurately phrased, "Any idea when > Rakudo will release implementing the full Perl 6.c?" > > -- Darren Duncan > > On 2017-07-25 1:02 AM, Elizabeth Mattijsen wrote: >> >> If that is the question, the answer is: the junction of “never" and “now". >> Which would also be the answer for Pumpking Perl 5, or any other programming >> language like ever. Because as long as people are using it, a programming >> language will evolve. Much like any human endeavour I would say. >> >>> On 25 Jul 2017, at 09:42, Andrew Kirkpatrick <uberm...@gmail.com> wrote: >>> >>> I assume the meaning is, roughly when is the implementation expected >>> to cover the entire spec? >>> >>> Answering this is probably an exercise in futility, because its up to >>> the community and not anyone in particular. >>> >>> On 25 July 2017 at 17:00, Elizabeth Mattijsen <l...@dijkmat.nl> wrote: > > [snip] > >>>>> >>>>> >>>>> Any idea when the full Rakudo will be released? >>>> >>>> >>>> What do you mean by “the full Rakudo” ? Rakudo Star is the Rakudo >>>> compiler release with a set of useful modules added (“batteries included”). >>>> >>>> So you could argue that Rakudo doesn’t get fuller than with Rakudo Star! >> >> > -- raiph
