G'day reverendmred,

Welcome to the Monastery.

"Now, Perl6 has changed all the rules."

I wasn't certain if you were clear on this, so, just to clarify the situation, Perl6 is not the latest version, or a simple update, of Perl5. They are different languages, with their own syntaxes. Except in the most trivial cases, you can't run Perl5 source as Perl6, or vice versa. Here's an example of the level of triviality that I'm talking about:

$ perl -e 'print "Hello, world!\n"'
Hello, world!
$ perl6 -e 'print "Hello, world!\n"'
Hello, world!
$
[download]

Perl6 has many similarities to Perl5, but they're not the same language. See https://docs.perl6.org/language/5to6-nutshell ("Perl 5 to Perl 6, in a nutshell: How do I do what I used to do?"). There's a number of other 5to6-* links in https://docs.perl6.org/language.html ("Perl 6 Language Documentation").

Perl6 is considered a sister language to Perl5 (see https://perl6.org/). Perl5 is the language to (continue to) choose for robust, production-grade code.

"Once long ago, we used the top of the file to point the script at the executable."

Long ago, and still today! That's called the shebang line. You could use either of these as the first line of your Perl script:

#!/usr/bin/env perl
#!/usr/bin/env perl6
[download]

"... if you had good OO like Perl5 code, there should be no problem running it alongside new Perl6 code ..."

Yes, you can have both Perl5 and Perl6 code in the same source. See https://github.com/rakudo-p5/v5 for example code; follow links therein for further details.

"So, is there a way we can fork projects and modules on CPAN?"

Not really my area of expertise; however, https://modules.perl6.org/ has links to information about creating modules for Perl6.

Perl5 Perl6 forking

What's "Perl5 Perl6 forking"? The rest of your comment made more sense to me so I'll focus on that in what follows.

Is there any way to ensure a switch in Perl 6 so you can choose between languages?

About 15 years ago Larry wrote that "Perl 6 must assume it is being fed Perl 5 code until it knows otherwise". The current Rakudo Perl 6 compiler does not comply with this "speculation" but that's probably because the situation has changed from what was perhaps expected back then: the Rakudo Perl 6 compiler goes by the name `perl6`, not `perl`, which instantly eliminates many of the potential accidental wrong language execution scenarios due to there being two Perls.

Continuing, Larry wrote "We ... have to figure out how Perl 6 main programs should distinguish themselves from Perl 5 (with a "use 6.0" maybe?)".

The syntax has ended up being `use v6.c;` or `use v6.d.PREVIEW;` etc. A `use 5....` or `use v5...` fed to Rakudo yields a "no such routine `use`" compile time error.

Larry also noted that "If you go out to CPAN and look at every single module out there, what do you see at the top? Answer: a "package" declaration. ... I hereby declare that a package declaration at the front of a file unambiguously indicates you are parsing Perl 5 code.".

But fast forward to today and instead of Rakudo using a heuristic to detect which language a module is written in, the module's language must be explicitly specified in its `use` statement if it's not Perl 6, eg:

use v6.c;
use Mojo::UserAgent:from<Perl5>;
[download]

Once long ago, we used the top of the file to point the script at the executable.

Yes, a shebang could be another way for a compiler to decide what language it's dealing with.

Can we have Perl6 provide something like this to preserve legacy code.

I am sure that Perl 6 will deal properly with existing Perl 5 code but please note that Perl 5 code is not, in the general case, legacy code. (Asked recently if "Perl 6 will replace Perl 5" Larry answered, quite sincerely I think, "probably, in about 40 years or so.")

It would also be nice for CPAN modules to provide a fork so we can keep alive old stable code.

Again, Perl 5 code and CPAN modules are staying right where they are and they are not at risk.

There's talk of putting Perl 6 modules (by which I mean modules written in Perl 6 code, not modules with Perl 6 in their name) on CPAN. But CPAN (or maybe PAUSE) doesn't currently support the Perl 6 notion of having module forks (modules with the same name but written by different authors) so it's going to take time before Perl 6 modules start appearing on CPAN in bulk -- if they ever do.

Regardless, those maintaining CPAN are not going to allow Perl 6 to cause disruption.

use Inline::Perl5;
[download]

Take a look at this: https://github.com/niner/Inline-Perl5

Note that it seems that you can also run P6 modules from P5, but I haven't really investigated this.

Languages need to evolve, but when C evolved into different varieties, ultimately, it was called a different language. The same seems to be true of Perl.

update: A new attempt at expressing my thought: The difference between Perl 5 and 6 is much greater than the relative difference between C and C++. The code for my last C project the C code needed to be compatible with 4 compilers, 2 in C and 2 in C++. This is possible when writing new C code; however, an arbitrary existing program may or may not compile with a C++ compiler.

It is true that interfacing C and C++ binaries complied under different compliers can be problematic because at a fundamental level, each language uses a different subroutine calling protocol. In C the calling program manages the assembly lauguage stack. In C++, the callee (the subroutine) manages the assembly lauguage stack.

But this linking difference does not rise to the level of "a different language", at least not at the source code level.

If you like OO, the big difference in Perl over the past years has been better ways of doing it. Perl 5 OO has become much easier than it used to be.

I will leave it to other Monks to talk about Perl 5 OO, Moose, Moo and the tools that have become mainstream Perl 5 OO for users.

If you have older Perl 5 OO code, there is no problem running it together with more modern Perl 5 OO implementations. I suggest you become more informed about Perl 5 advances since you last used Perl in an OO environment.

Perl 6 is a completely different language from Perl 5. This is not at all like C versus C++.

If you mean that C++ is a "different" language than C, that is wrong. C++ is a superset of C. This backward compatibility required a lot compromises. Ancient C code will compile using a C++ compiler.

Sorry, but while most C code will compile using a C++ compiler, C++ is not a superset of C, and there is code that a C++ compiler won't compile successfully. There are C constructs that a C++ compiler will refuse; and extensions of newer C standards (like C99) are not available in a C++ compiler. Also, some constructs behave differently in C and C++.

There is a long article in the Wikipeda explaining the Compatibility of C and C++.

Also, C is not a subset of C++, according to Bjarne Stroustrup, creator of C++.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Alexander, yes you are correct and your post++ is more precise than mine. I updated my post. My word choice of "superset" is wrong. I know a lot more about C++ than I do about Perl 6, but I believe my basic point about relative similarity between the languages is true. I believe that some basic syntax in Perl 6, perhaps array access is just incompatible with Perl 5. I can write new C code that will work under both compilers (and have done so). I do not think that is possible with Perl5/6.

Seems to me based on this:

"The point is, if you had good OO like Perl5 code, there should be no problem running it alongside new Perl6 code as long as you treat them as separate languages and you have a fork of the legacy CPAN code. What you need to make sure is that the interfaces between your Perl5 and Perl6 code are stable and work."

...is that you're making a statement, more than you're asking a question.

I've done some dabbling in perl6, and I say I quite like it, but you probably want to speak to someone like moritz to get specifics. He's someone I trust knows a thing or two, after dealing with him here on PM, and bouncing things off off in IRC.

So, is there a way we can fork projects and modules on CPAN? This would be really, really useful.

Hi,

What exactly do you mean by that?