Re: Re^3: Perl 5 -> 6 do's and don'ts? (Inline::C)

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.

Comment on Re: Re^3: Perl 5 -> 6 do's and don'ts? (Inline::C)

Replies are listed 'Best First'.
Re^5: Perl 5 -> 6 do's and don'ts? (Inline::C) by tye (Sage) on Aug 01, 2003 at 20:52 UTC
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	[reply]

Replies are listed 'Best First'.

Re^5: Perl 5 -> 6 do's and don'ts? (Inline::C)
by tye (Sage) on Aug 01, 2003 at 20:52 UTC

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

[reply]