rakudo VS Inline-Perl5

Fix IO::Path::parent #4795: merged 2022-02-19 Add more IO::Path::parent tests #801: merged 2022-02-19 Change parent to always just remove the last element #4800: merged 2022-02-26 Change .parent behavior to "stupid" resolving #802: merged 2022-02-26

This then became the Formatter class. And since this was a completely new feature, it only became available for use by opting into the 6.e.PREVIEW language version. And then it went largely unnoticed and uncared for the next 1.5 year. As clearly the time wasn't right for it yet.

The intended audience are those people willing to be early adopters of these exciting new features in the Raku Programming Language. The examples in this blog post will work in the next release of the Rakudo compiler (probably 2023.06), but are now already available in the bleeding edge version.

If you really want to look at this, you can find the code in src/Perl6/Grammar.nqp, src/Perl6/Actions.nqp and src/Perl6/World.nqp.

If you find this very interesting, you probably want to read the RakuAST README. And the actual source code of the RakuAST classes can be found in the same directory. And if you're really feeling adventurous and you have the Rakudo repository checked out, you can have a look at the generated NQP code in gen/moar/ast.nqp.

Yes, it would. But until there was RakuAST, that was virtually impossible to do because there was no proper API for building ASTs. Nor was there an interface to execute those ASTs. And now that there is RakuAST, it is actually possible to do this. And there is actually already an implementation of that idea in the new Formatter class. Although this is definitely not intended as an entry point into grokking RakuAST.

I have opened one. https://github.com/rakudo/rakudo/issues/5205.

Will Coleda has made a Pull Request

There's an issue pertaining to this. This is something I'd like to resolve, but I'm unsure on how to better debug this to see if it really is the deserialization of a setting file triggering it. JDK 11 should at least be capable of building Rakudo, but being an experimental backend people don't always align with MoarVM immediately, I can't make any guarantees about tests. You may be disappointed in its performance at the moment.

(NB. While the PL is just a toy (and just a tiny bit of the toy too), the tech is actually industrial strength, used to power the production Raku compiler, which is written in Raku using its grammar construct. Starting easy doesn't mean you can't go far. Quite the opposite in fact -- you can go as far as you want.)

Verbatim from the documentation at https://github.com/niner/Inline-Perl5: use Inline::Perl5;

> Perl 6 was treated as the successor of Perl 5 -- and that was the mistake. It meant Perl 5 started dying,

Perl 6 took a long time to make, but how much did that matter? What was Perl going to do about Rails, Clojure, Go, Rust, JS/TS, and more? The world of programming languages used to be a lot smaller than it is today.

> Perl 6 had a new different syntax.

Inline::Perl5 [3] allows running legacy Perl 5 code in Perl 6 codebases.

[1]: https://docs.raku.org/language/5to6-nutshell#Regular_express...

[2]: https://github.com/atweiden/voidvault

[3]: https://github.com/niner/Inline-Perl5

Perl can be faster and defiantly nicer to work with than PHP but it's nowhere near as fast as some other options like Rust but that has the downside of being much harder to write and get working. Perl has the advantage of being prepackaged with the base system and on OpenBSD it's kept up fairly well with the system version currently being only one version behind the latest yearly Perl release. There are some patches added to the OpenBSD version so updating it each year takes time. The easiest way that I've found for running Perl websites is to leave the system modules as is and to install all of the modules that you need into a users home directory with local::lib and cpanm. That way the system install isn't contaminated with the extra modules and it makes deploying easy because it's all contained in one users home directory that can be rsync'd or tar'd. Another nice thing is you get access to pledge and unveil through Perl so you can lock down your website even further. I've recently been trying out doing things in Raku (Perl6 was renamed to Raku in 2019). It's slower than Perl most of the time but I find Raku to be so much more beautiful and expressive that it's a joy to code with. There aren't as many modules available right now for Raku but it gives you access to all of CPAN through the Inline::Perl5 module.

Interfacing with Perl 5 with Inline::Perl5:

I'll be happy to dialog about this compatibility, but the key thing is to start with an open mind; a recognition that the original vision predated Parrot; and a recognition that Rakoons have never relinquished that original vision even while many of us are delighted that Perl folk are keeping Perl healthy as a separate thing in its own right.

To be clear, the realization of Larry's original vision is not constrained to interop with Perl. Raku has extraordinary potential, some already realized, for pan-language compatibility via its [Inlines](https://modules.raku.org/search/?q=inline).

The steady improvement of [the exemplar Inline](https://github.com/niner/Inline-Perl5) for the last 6 years; its evident maturing; its suitability as a solid blueprint for upgrading all the others; all of this bodes well for being able to use a lot of the world's best existing code from within Raku this decade, with Inline::Python quite plausibly shining in this regard within the next 2-3 years.

[1] https://stackoverflow.com/a/45181464/1077672

The most polished of the Inlines, namely Inline::Perl5 (github repo) enables devs to instantiate Raku objects that are instances of Raku classes that are sub-classes of Perl classes. It does this even though Perl has pluggable OO, essentially arbitrary OO, with dozens of different OO systems available, all of which differ from Raku's, for example having a variety of MRO linearizations that aren't C3. So such things can be done.