Thanks for all the responses, and I agree with them.

At the same time, I think I was misunderstood, so I will try and clarify my position now.

1. I fully understand the distinction between a version of the Perl 6 language spec, or of components thereof (such as of grammar, standard library, test suite, etc), and a version of a Perl 6 implementation or component thereof (such as Rakudo, NQP, MoarVM, JVM etc), and a version of a distributing package of the above (such as Rakudo Star, or Debian packages, or CentOS packages, etc).

2. I advocate such a separation and distinct versioning of such things as the above. The Rakudo version and Perl 6 spec version are not the same and shouldn't be.

3. Code written in Perl 6 should declare at least one version of the Perl 6 spec it conforms to and should be treated as, optionally a version it is known not to conform to, etc. Unlike some other people, I think declaring such a version the code expects to work with should be mandatory. Each implementation will either natively support a declared version, or emulate it, or not support it, etc.

4. As a key point to this discussion, I believe that something as complicated as the Perl 6 spec itself is bound to have regular updates or bug fixes itself, where bug means either a documentation mistake or a bug in the test suite etc. As such, I believe it is perfectly reasonable for the Perl 6 spec itself to have more finely grained version numbers.

5. Given the prior point, I had until now understood Perl 6.c, 6.d etc, which I only realized the existence of that scheme in the last month or so, to be transitional names, and we would use a number-based scheme at some point, for the language spec itself. Perhaps with a semantic version where incrementing some numbers added features or possibly removed them, and other numbers just fixed bugs without being considered a forwards or backwards breaking change.

Here's a question:

If language specifications trail implementations by a significant margin, then how does Perl 6 code idiomatically declare that it depends on features that say Rakudo added which aren't in the spec? Does it use an "auth" of "Rakudo" or something like that? I didn't see your talk so maybe you covered this.

Note, up until now, I had considered using alternate "auth" to indicate a fork of the spec or such, though in hindsight of your implementations leading spec comment, I assume this is also how one indicates dependencies on a spec-leading compiler.

Thank you.

-- Darren Duncan

On 2015-12-29 5:46 AM, Patrick R. Michaud wrote:
On Tue, Dec 29, 2015 at 01:57:57AM -0800, Darren Duncan wrote:
On that note, are there going to be Perl 6 versions 6.x.y where {x,y} are
integers?  Will 6.0.0 be the first such one? -- Darren Duncan

This was the topic of my FOSDEM talk last year, and then again at YAPC::NA.

"Perl 6" is a language, not an implementation of that language.  Think of "Perl 6" as being like 
"C", "C++", "Javascript", etc., where the language is separate from the (many) implementations of 
that language.

There are two key points to make:

1.  Language specification should follow implementations, not precede them.  
This has been found to be true for many programming languages, and it's the way 
things work in the Internet RFC/STD process.  An update to a language spec 
recognizes and ratifies the features that have been largely agreed upon by 
implementations and users, as opposed to prescribing what the next version of 
the language ought to look like.  First is rough consensus, then running code, 
and *then* formalization into a specification.

So, if language specification follows implementation, it's not possible for Rakudo or other implementations to use 
language version numbers as their primary versioning scheme.  To take an example from the C language:  My gcc compiler 
says it's version 5.2.1, but there's not a version "5.2.1" of the C Programming Language.  Similarly, one 
doesn't speak of the "C89", "C99", or "C11" release of GCC.

2.  It doesn't make a lot of sense to think of major/minor version numbers such as 6.x.y when discussing a language 
specification.  Compiler releases happen often, incorporating new features, bug fixes, and small incremental changes.  
Language specification changes tend to happen on longer timescales -- there's not really a notion of a "minor 
release" on such timescales.  So, the language specifications are being versioned as "6.a", 
"6.b", "6.c", etc., instead of a scheme incorporating minor version increments.

Yes, this separation of language specification and implementation can be unnerving to 
those that are so used to Perl 5's tight coupling of the two, including using a common 
"version number" for both.  But that tight coupling is partly what led to 
several of Perl 5's evolutionary dead ends and roadblocks, and we're trying to avoid 
repeating that mistake with Perl 6.

On Tue, Dec 29, 2015 at 01:57:57AM -0800, Darren Duncan wrote:
On that note, are there going to be Perl 6 versions 6.x.y where {x,y} are
integers?  Will 6.0.0 be the first such one? -- Darren Duncan

On 2015-12-29 12:51 AM, Tobias Leich wrote:
Hi, the first official Perl 6 (the language) release is not called 6.0.0, it is
called 6.c.
And this is what has been shipped with the Rakudo compiler release 2015.12.

Reply via email to