Front page | perl.perl6.announce.rfc |
Postings from September 2000
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
linkable output mode
=head1 VERSION
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
=head1 changes
Addition of sentences concerning "perl without perl"
=head1 ABSTRACT
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 C< -o > command line switch identical
to that used in C compilers to produce a linkable object file.
=head1 DESCRIPTION
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 C< 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
=head1 IMPLEMENTATION
Given a nonprototyped subroutine, C<perl6 -o> will
generate suitable wrapper
code for all subroutines in the input file, as described in the L<perlcall>
and L<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.
=head1 REFERENCES
my imagination
perldoc perlembed
perldoc perlcall