I'll somewhat disagree with Abigail-II and Elian.

Yes, if you want to interface Perl5 to a C library, then doing so via Inline::C is more likely to make it easy to port to Perl6 than using XS would (the XS porting might be available sooner, but you have much more risk of doing something that won't be handled if you use XS, IMHO).

Using Inline::C or XS to manipulate Perl data structures is something I simply don't recommend and I find that avoiding it when interfacing a library usually makes for a better design anyway.

C code that manipulates Perl data structures has always been the first thing to break when Perl is upgraded. So asking how to do that with Perl6 in mind calls the answer "Don't!" to mind (which is my answer anyway, just not as emphatically).

So when someone asks how to use XS with Perl 6 in mind, my advice is "Don't manipulate any Perl data structures in C and use Inline::C instead of XS." But, that is my advice anyway (again). And I'll bet that modules that follow that advice will eventually be able to work with Perl 6 without requiring any "by-hand" porting.

I'll somewhat disagree with Abigail-II and Elian.

Yes, if you want to interface Perl5 to a C library, then doing so via Inline::C is more likely to make it easy to port to Perl6 than using XS would (the XS porting might be available sooner, but you have much more risk of doing something that won't be handled if you use XS, IMHO).

YHO would be very incorrect in this case. The issues involved are entirely those of the perl API, and have nothing to do with the means to generate the C code to access that API. There are no problems one will encounter with XS that one won't in Inline::C, and vice versa.

The means of generating the C code has no bearing on the potential level of trouble. The issues are entirely ones of the perl API.

You seem to have misunderstood my point. I don't care how the C code is generated.

The issues involved are entirely those of the perl API

Yes, and my point was that it can be very useful to write stuff in Inline::C that makes absolutely no reference to the perl API. You simply write C code that takes C-style arguments. If you do that, then you don't need any macros or processing of the source code other than whatever needs to happen to turn the perl subroutine arguments into C data types and to turn the returned C data type into a Perl scalar.

And the available transformations to/from C data types are quite limited so you won't be doing anything in that part of your C code that won't be tons easier to implement than the whole typemap power of XS.

Yes, you certainly can write Inline::C code that will be horribly hard to port. I thought you two covered that point rather well. But I don't consider that the most important point.

                - tye

Abigail

At least Inline::C's abstraction layer could be easily ported to Perl 6. If inside your C code you're doing stuff to Perl (5)'s internals without using the proper macro's, then of course you're on your own.

So I guess I would put using Inline::C for a new Perl 5 project over using XS, especially knowing that Inline::C will be in the 5.10 core.

Liz

Well, yes, but that's only when you are doing something in pure C. If you now do something in pure C, and use XS for it, porting it to Perl6/Parrot would be reasonable straightforward. But a lot of XS code deals with Perl internals, whether that's pure XS or Inline::C.

especially knowing that Inline::C will be in the 5.10 core.

Right. 5.10. When will that happen? After more than a year, we still have no 5.9.0, or even goals for 5.9.0. I might be pessimistic, but I think any new Perl development going on that's going to be released "soon" will be found in 5.8.2 and 5.6.2/3. I had hoped the p5p BOF in Paris would shed some light on the timepath for 5.10, but there wasn't anything in the minutes, so I guess it wasn't discussed.

Abigail

Any non-specious reason to not use XS applies to Inline::C as well.