[crncosta]

I like P6 syntax and semantic more them P5.

My only one problem about P6 is the fact they dropped the effort of having the specification so others can implement the language too. Looks like they prefer a conformance test instead of a formal/complete specification.

While that is perfect fine, I would say having both the test and the spec is even better, for those trying to learn and implement the language.

A good, formal and complete specification will make my learning process much better, IMHO.

[chrisseaton]

I've recently been implementing a language based on a conformance test instead of a spec, and it's really hard. I often have two tests that do different things with seemingly similar inputs, and I struggle to find the underlying reason behind what is going on and what the cause of the difference in output is.

[Ulti]

There are still the design docs (http://design.perl6.org/) which are essentially spec documents. They are what implementors have been using over the years. Don't forget the tests came from Pugs and now Rakudo is using the same test suite, so it's more portable than you perhaps imagine. The tests are the stamp of approval for a version number conformance. If you can pass all the versioned tests then you are that version of the language. I think that's a lot stronger statement than the engineers think they understood a spec document, even if formally specified. What are your thoughts on why that isn't ok or worse than relying on pure docs?

[raiph]

I think you've misunderstood the original intent as expressed by Larry Wall in 2000, the current situation, and the future intent and practical realities.

For the original intent I'll quote Larry from the day he announced Perl 6 in 2000[1]:

"I don't know how strict a spec it will be from the language design point of view. I'm not really big on that sort of spec and there is some value to using the reference implementation approach and what we currently have is a reference implementation [with] no second implementation, well, unless you count the JVM work, but, obviously there are benefits to having things justified well enough that you could implement another one even if you didn't want to, so we'll definitely be working in that direction and - do you have something? And there was something else I was going to say - what we particularly want to stress in terms of - is not perhaps so much the spec as developing our current regression test. Well, we call them regression tests, but they're almost more acceptance tests, but, we developed our acceptance into real regression tests then you'd further develop the real regression tests into a validation test of what the language actually means and actually go out and explore all the nooks and crannies and say, "This is Perl, this is not Perl," and then we actually have a machine-readable spec. And to me that's actually a lot more important than what the verbiage on the human readable thing says."

I think the 6.Christmas release corresponds fairly directly to this original intent.

In the meantime the spec docs (as against the spec test suite), which are currently referred to as either "speculations" or "design docs" to better emphasize their contemporary role, are currently well behind the test suite and implementation. This is presumably what caught your attention.

The current thinking is that Perl 6 will follow the pattern adopted by many other mainstream languages in terms of the timing of development and publication of a relatively formal and debugged prose specification.[2]

This thinking in turn suggests it would be best if the spec docs caught up with the spec test suite and Rakudo and were then polished and formally published in a frozen form, some years from now.

At that point making a significant effort to provide practical support for alternate compiler implementations ought once again become compelling.

[1] http://www.perl.com/pub/2000/10/23/soto2000.html

[2] http://pmichaud.com/2015/pres/fosdem-specs/fosdem-specs-1.pd...