This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Kick out all ops - libprt =head1 VERSION Maintainer: Simon Cozens <[EMAIL PROTECTED]> Date: 25 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 315 Version: 1 Status: Developing =head1 ABSTRACT At least for the run time library used by Perl programs, kick all ops out of core. =head1 DESCRIPTION One of the problems with the current Perl compiler is that you have to carry a Perl run time around with you, and a run time library for the Perl virtual machine is pretty big, because core's pretty big. So, make core smaller. I'd like to extend this also to the whole virtual machine, because, for instance, there's little point having network stuff in core if you can't do any networking on your Furby. However, I'm going to restrict the scope of this RFC to the run time library (let's call it F<libprt>) which is used by compiled programs. So, have F<libprt> contain little other than the business of setting up and tearing down the interpreter, plus variable manipulation and scope, (actually, what's in F<libprt> is configurable at Perl installation time - more on that later) and have the byte-compiled program supply the other ops it needs. As usual, the interesting bit is how this is done. =head1 IMPLEMENTATION First, arrange our ops into groups; stick all the network functions into one op group, all the systems functions into another, and so on. As the compiler comes across an op in the op tree of the program it's compiling, it'll make a note that the program needs to use the op group containing that op. When F<libprt> is created, the user selects which op groups should always be present: this is similar to deciding which XS modules should be statically linked into perl. The compiler checks to see which op groups a program needs which aren't in F<libprt>. Depending on what bytecode looks like, it can either insert something which requests that op group from a dynamic library when the program is run, or inserts the object code to implement that op group directly into the output. This method of auto-detecting necessary op groups might not always work, notably since C<eval> exists. Hence, the program should be able to provide compile-time hints to the compiler as to what additional op groups should be requested: use opgroup 'network'; will cause the network functions to be loaded in the produced bytecode. =head1 REFERENCES None.
