| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
linkable output mode
Maintainer: David Nicol <perl6rfc@davidnicol.com> Date: 17 Aug 2000 Last Modified: 20 Sep 2000 Mailing List: perl6-language@perl.org Number: 121 Version: 2 Status: Frozen
Addition of sentences concerning "perl without perl"
Perl5 offers a clunky interface for those who
wish to call perl subroutines from within C programs.
Herein is suggested a vastly simplified application
programmer's interface: a -o command line switch identical
to that used in C compilers to produce a linkable object file.
Two command line switches, -o and -oh, are added to perl6's invocation syntax.
Perl invoked with the -o switch does not run its program, but rather pukes out an "object file" same way gcc would if given a file full of C code.
Perl invoked with the -oh switch does not run its program, but rather pukes out a "header file" suitable for inclusion into a C program, containing the correct linkage definitions for the object file created by the -o switch.
The resulting object file must be linked with the perl library to work.
The point is, the perl internals are effectively hidden from the programmer who wishes to use a feature available in perl from within a C program.
Also, it becomes easier to generate a "stand-alone" deliverable
which will work without a full Perl intallation, by linking the
output of perl -o into a simple main() and delivering the resulting
linked binary along with a perl shared object library. Or by just
doing something like this:
perl -o deliverme.o deliverme.pl
ld deliverme.o -o deliverme
Given a nonprototyped subroutine, perl6 -o will
generate suitable wrapper
code for all subroutines in the input file, as described in the perlcall
and perlembed perldoc pages, and then pass this code (via a temporary file)
to the same C compiler that was used to build perl.
Given a perl6 subroutine with a fully described prototype, which amounts to a C struct structure, that structure (with its names if any) can be used as the parameter types of the resulting function call. A restricted return type described in terms of basic C data types can function as a C function return type.
Perl functions that are already using restricted parameter lists and restricted return types are effectively doing their own type conversions, except between SV{STRING} and char*, but allowing C access to the SV{STRING} data type and functions can't be anything but good.
Furthermore, the porting team will need to get very chummy with the linking system on the platform.
my imagination
perldoc perlembed
perldoc perlcall