Re: Refactoring Perl5 with XS++

[ikegami]

XS is means of exposing C functions to Perl programs. This can be quite trivial, but you can also include C code to handle more complex types or to provide a more Perlish interface. A simple XS module:

#define PERL_NO_GET_CONTEXT
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#include <math.h>

MODULE = MyModule  PACKAGE = MyModule

double
sin(double x)

package MyModule;
use strict;
use warnings;
use Exporter qw( import );
use DynaLoader qw( );
our @EXPORT_OK = qw( sin );
bootstrap __PACKAGE__;
1;

That said, I suspect Chromatic was referring to the Perl API rather than XS. (And even then, probably to a subset of it.) The Perl API allows you to create Perl variables and manipulate them. You also have access to Perl's stack, and you can call Perl subs. (XS code can use the Perl API.)

[rje]

Maybe so. Re-reading his post, though, it looks like he has wanted something that replaces XS, as well.

He lays out three steps. First, a minimal bootstrapping language which can replace XS. Second, Rakudo's intermediate structure to represent the language (or something better). Third, Rakudo's metaprogramming system (or something better).

To hammer the point home, he then says "Figuring out a replacement for XS is essential".

And in another place, he actually tried writing a little bytecode interpreter which granted the power of C, without having to write in C. I think that's one peep into his vision, in a way.

[ikegami]

The fact that the document is about replacing XS doesn't change what I said. XS is no more a programming language than HTML is. The ops his bootstrapping language would have would have parallels in the Perl API, not XS.

[rje]

Ah! Yes, I think you're right.

[mr_mischief]

I think a pertinent question, then, is replace XS how? In one sense, XS is easily replaced if one has a powerful enough foreign function interface (FFI). In another sense, syntax that allows (possibly inlined) C to be separately compiled and to call back into Perl easily is required. If one wants to fully replace XS, the language has to be able to do both or do equivalent things to both.

[rje]

Quite so! And that's pretty much where I'm at: "in what sense would XS be 'replaced'"? And of course it's probably more like robustifying the API so that XS is directly used less often, or never if possible.

Note that I'm not assuming any of this is likely or easily doable. Hard things are possible, though.