I don't know if this has been discussed before, but I'm just tossing this
idea on the table for discussion and consideration. (If this was already
discussed, please tell me what the conclusion was, if any.)
How about implementing the Perl 6 compiler in Perl 6 itself?
Note that I'm _not_ talking about the runtime environment needed to execute
Perl code, but the compiler code that parses the Perl source and generates
bytecode, syntax trees, C code, or whatever else. If we take an analogy to
Java, there could be a "Perl Virtual Machine" (for lack of a better term)
providing the runtime environment -- the "PVM" would be written in portable
C code, but the Perl compiler could be in Perl.
I expect there will be objections on the basis of efficiency. Indeed, I'm
a little concerned about this myself. Then again, if it CAN be made "fast
enough" in Perl, that would make a good example for those who assume that
Perl (as a "scripting" language) must not be fast or powerful enough for a
full-blown application. And if it can't be fast enough, that could be an
indication that people _should_ be concerned about doing something in Perl
that might be too slow?
The main advantage of writing the Perl compiler in C (a la Perl 5) is
(obviously) speed. Memory efficiency is probably the next significant
benefit. Portability would normally be a benefit, but Perl is actually
more portable than C, and if the Perl 6 compiler is written in Perl 6,
it's providing its own implementation platform to build on. Beyond that,
I'm not sure a C-based compiler really has much to recommend it. And with
machines consistently getting faster and larger, maybe these arguments for
a C-based implementation are getting less and less compelling?
Off the top of my head, here's some _potential_ advantages I can see for a
Perl-based compiler implementation: (some might not pan out in practice)
* Feedback: Implementing the compiler in Perl might serve as an important
source of feedback for language design and implementation issues; the
design of the language or implementation could be adapted (if necessary)
to allow for a more efficient Perl-based compiler implementation, which
might help other real-world Perl programs in the future.
* Ease of implementation: With the power, flexibility and expressiveness
of the full Perl 6 language available, it should be MUCH easier to
implement the compiler in Perl than in C, especially if well-designed.
* Speed of implementation: Perl programs don't take nearly as long to
write and debug as C programs do. It would certainly be nice if Perl 6
doesn't take several years (like Mozilla) to get to production status.
(Perhaps a Perl implementation could be done in closer to one year than
three or more?)
* Correctness: Perl references are safer than C pointers, there is no need
for concern about details of memory management in Perl, and the complex
data structures in Perl are easy to build. Many related bugs (including
security bugs such as buffer overflows) that would be commonly found in
C code wouldn't be likely to occur in a Perl implementation. (Again,
this would help with the speed of implementation.)
* Security: It would be possible to compile Perl programs to execute in an
environment where the Perl runtime is available, but the Perl compiler
is NOT available. This could be useful for places such as firewalls,
where providing a compiler could simplify a cracker's job if they get
far enough to access it.
* High-level: An object-oriented implementation could be cleaner and more
understandable, and Perl offers a lot of high-level functionality that
could be used to advantage in the compiler. While C++ could offer the
ability to have an object-oriented compiler, it's less portable than C.
OO techniques can be used in C, of course, but the language can't help.
* Maintainability: A well-designed object-oriented Perl implementation
should be highly maintainable, not only because of the higher-level Perl
functionality and OO encapsulation, but also because of the sheer volume
of code -- a Perl implementation probably doesn't need to be nearly as
much code as the equivalent C implementation is likely to be.
* Flexibility: It should be straightforward to plug in different compiler
front ends (e.g. Perl 4/5/6 versions, Java, Python, etc.) to handle
various languages/dialects, and to plug in different compiler back ends
(e.g. Perl or Java/JVM bytecode generator, portable C code generator
(with or without runtime environment or library required), etc.)...
Adding new such modules would be easy to do at any time.
* Leveraging functionality: Some of Perl's greatest strengths revolve
around text processing, regular expressions, manipulation and
correlation of complex data, etc. Compiler implementation seems like a
natural extension of this. Perhaps some core language changes (such as
exposing some of the NFA functionality underlying regular expressions)
and some additional code (in C and/or Perl) could be written to enable
scanners and parsers of all sorts, which could benefit not only a Perl
compiler implementation, but Perl programs of all sorts that have to
parse structured data (little languages, config files, XML, etc.)
* High performance possible: Writing a Perl-based compiler implementation
doesn't preclude also writing a high-performance C implementation later,
should it prove necessary. (In that case, the Perl implementation could
be viewed as a prototype implementation, from the perspective of the
authors of the C version.)
* Embeddability: Subsets of the language could be defined for embedded
environments with simpler compilers and/or simpler runtime environments.
I'm sure there's more that I'm not thinking of now, and maybe some of these
ideas won't make sense in the end. Still, I believe there's a lot that can
be gained by implementing the Perl 6 compiler in Perl 6, and I'm hoping
that people will seriously consider the idea (if they haven't already)...
What does everyone else think of this possible approach?
Deven
