[% setvar title Kick out all ops - libprt %]

This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/


Kick out all ops - libprt


  Maintainer: Simon Cozens <simon@brecon.co.uk>
  Date: 25 Sep 2000
  Mailing List: perl6-internals@perl.org
  Number: 315
  Version: 1
  Status: Developing


At least for the run time library used by Perl programs, kick all ops out of core.


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 libprt) which is used by compiled programs.

So, have libprt contain little other than the business of setting up and tearing down the interpreter, plus variable manipulation and scope, (actually, what's in 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.


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 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 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 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.