Good luck with C# :)

I had assumed, perhaps wrongly, that the XS mechanism allows Perl to be connected to any compiled language, at least in theory... So it could be used with Ada or Zig or anything in between.

Not directly, no. From perlxs:

XS is an interface description file format used to create an extension interface between Perl and C code (or a C library) which one wishes to use with Perl.

...

The glue code pulls the arguments from the Perl stack, converts these Perl values to the formats expected by a C function, calls this C function, and then transfers the return values of the C function back to Perl.

So XS is inextricably tied to C. That is not to say that you could not use XS via C as a conduit to access other, non-C code but it would be a bit Heath Robinson. Perhaps FFI::Platypus would be a better bet for that.

FTAOD, I am in no way an XS expert and can count on the fingers of one hand the number of times I have written such code so treat all this with a little scepticism.

---

🦛

I had assumed, perhaps wrongly, that the XS mechanism allows Perl to be connected to any compiled language, at least in theory...

Unfortunately not. As someone already mentioned, it has the capability to play nice with C++ code (wiringPi is in fact C++ based), but there are a lot of gotchas that can prevent it from working, and often requires overriding/rewriting the functions that don't work in pure C before they can be presented through the Perl library.

I also write a fair amount of C# code (berrybrew would be my most complex example), but wrapping something like that with XS would be an impossible, futile, headdesking task.

XS is always C, but can call into anything that exposes C-compatible functions in a shared library. So, C works, and C++ works as long as the author of the C++ module exposes plain-old-functions with C calling convention. There are other languages like Rust that can expose C functions from a compiled library even though the library was generated from Rust code. In fact, quite a lot of compiled languages can expose C library APIs just because C is sort of like a common meeting ground for interoperation and language designers want their modules to be widely usable. But XS can't just call into arbitrary other languages on their home turf.

Also I'd hesitate to call C# a compiled language. It's more like a bytecode interpreted language with optional just-in-time compilation. I don't think it can generate .so or .dll files with C calling convention. (but I'm too lazy to go find out)

It is possible to wrap C# in C++, but it's something of a pain. Mind you, in my mind anything to do with C# is a pain so take from that what you want!

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

> I'd hesitate to call C# a compiled language. It's more like a bytecode interpreted language with optional just-in-time compilation

Agreed. And Just-in-time compilation and Adaptive optimization further muddy the performance waters. I'd call C# a statically-typed language, while Perl is dynamically-typed. Note BTW that (statically-typed) C/C++ can also do JIT/Adaptive optimization nowadays via LLVM and Clang.

As discussed in more detail here, static typing usually results in compiled code that executes faster.

👁️🍾👍🦟

> I had assumed, perhaps wrongly, that the XS mechanism allows Perl to be connected to any compiled language, at least in theory

While I'm not an XS expert -- and further to ++hippo's excellent reply -- I'd put both Java and C# in a separate category due to their reliance on an underlying virtual machine.

I'm not aware of any plans to implement Perl 5 on the JVM (Java) or the CLR (C#). That this would require a huge technical effort is indicated at:

• Re^2: Spoiled by Perl (JVM/CLR)

Update: from the FFI::Platypus docs:

Things not supported include languages that do not compile to machine code ... like .NET based languages and Java

👁️🍾👍🦟