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.
