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

Reply via email to