develooper Front page | perl.bootstrap | Postings from July 2000

Re: Working Group Proposal

Ken Fox
July 20, 2000 12:56
Re: Working Group Proposal
Message ID:
Benjamin Stuhl wrote:
> From: Ken Fox <>
> >The scheme48 project had a very good experience writing the core
> >in a reduced dialect of scheme. This reduced dialect could be "easily"
> >translated to a machine representation (they used C). I would support
> >a similar implementation of perl6. (The reduced perl could be the
> >ultra-portable microperl.)
> I like this idea. However, as performance is still somewhat of an issue (and
> perl5, at least, eats immense amounts of memory even in C), I would propose
> that the intermediate language (and that of the microperl6) be C, rather
> than something higher level with more overhead.

Joshua already outlined an implementation, but here's a bit more
detail of how it could work.

1. A micro-perl compiler is written in micro-perl. It generates whatever
   language we want, probably C code. Micro-perl is an easily compiled
   subset of Perl 5: No eval, no dynamic symbol table stuff, no BEGIN/END,
   no overloading, no garbage collection, etc. Using Perl 5 solves the
   bootstrap problem quickly. (The subset defined as micro-perl can grow
   to become a subset of Perl 6 as we implement more functionality in the
   compiler, i.e. the compiler compiles itself.)

2. A support library is written for the generated C code. This can either
   be written in micro-perl or in C. Micro-perl buys portability, but C
   would be able to re-use parts of perl5, like the regexp engine.

3. A Perl virtual machine (PVM) is written in micro-perl. Large
   potions of the PVM will be shared with the micro-perl compiler -- we
   will want compiled code to be compatible with the PVM. The PVM must
   read a Perl 6 parse tree, i.e. the output of the Perl 6 parser. We
   need standardized file formats for storing a parse tree.

3. A Perl 6 parser is written in micro-perl by extending the micro-perl
   compiler. The parser generates a parse tree for the PVM. It could
   be part of the PVM if the PVM implements string eval directly. (The parser
   probably needs to embed the PVM to support BEGIN/END so we might as well
   just make it monolithic anyways.)

Once the basics are working, we can go back and extend the compiler to
compile Perl 6 instead of micro-perl by embedding a PVM into the generated
code. (It would be nice to have a Perl 6-lite that can be compiled without
needing the entire PVM built-in, maybe a pragma?)

We should also go back and write a Java back-end for the micro-perl
compiler and a Java support library. (If we can find Java to native code
compilers of the same quality as C compilers, it would make sense to
target Java as the first back-end instead of C.)

This is a total change in direction from previous work done with Topaz.
I'd like to hear from Chip on how difficult the Topaz design is to work with
and whether the expense of a (high-quality) micro-perl compiler is worth
it. BTW, it's the PVM and parser I'm mostly interested in -- moving those
into micro-perl would make them much more fun to play with.

- Ken Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About