On Fri, 22 Dec 2000, Nicholas Clark wrote:
> On Fri, Dec 22, 2000 at 03:56:06PM -0500, Deven T. Corzine wrote:
> > Except for obvious performance-critical bottleneck areas, what advantages
> > are there to implementing anything else first in C?
>
> One reason (maybe not a good one) I can think of
>
> There are people who already have experience of writing perl in C.
> I don't think there's anyone with experience of writing a perl interpreter
> in perl.
>
> Not sure if that's a circular argument.
Well, that's true. Keep in mind, though, that the algorithms used are
often more important than the implementation language. Quicksort in BASIC
will usually be better than a highly-tuned hand-written implementation of
bubble sort in assembly language.
The people with that experience obviously need to understand Perl well
also, and their experience implementing the compiler in C should provide
valuable insights into implementing it again, in any language. Also, the
previous attempt to rewrite Perl in C++ should also provide valuable
insights, since it was probably more object-oriented in nature...
> People with experience of the innards of perl5 already know how how not
> to do some things for perl implemented in C. :-)
> Implementing perl in perl wouldn't give us this headstart. However,
> headstarts do not necessarily win races.
You could consider the existing codebase a headstart as well. However,
despite such a large headstart, a reimplementation from scratch might still
take less time than trying to continue from that headstart position. Also,
if the resulting code is cleaner and more maintainable, isn't that better?
> I'm also not totally sure how to bootstrap perl in perl. I have a C
> compiler that works, a perl interpreter that works, but I don't have total
> confidence in perl5's perl compiler. It might take quite a lot of perl5
> messy guts hacking to make perl5's compiler good enough to bootstrap a
> clean perl6 compiler to compile the perl systems to a binary.
If the compiler is to be object-oriented (whether in C or Perl), I think
there's enough unknown territory there that some missteps are probably to
be expected in the process. If it's not object-oriented, will we be able
to gain the maintainability and extensibility that's wanted of Perl 6?
There would definitely be a learning curve to implement the compiler in
an object-oriented fashion, whether in Perl or not. I think that most
compilers in the world are NOT object-oriented. Some are, but I don't know
if there's any consensus yet on how object-oriented compilers should be
designed and implemented. We should probably "plan to throw one away", as
Brooks would say. (Maybe throw two away, because of second-system effect?)
I've been wondering what features would make it easy to write a compiler in
Perl. The regex engine could help a lot with the scanner, but parsing
isn't quite as simple. Sometimes I wonder if the regex engine could be
extended to process tokens as atomic units, to make it suitable to provide
a base to implement the parser. Maybe the solution here is to do regex
substititions of tokens for Unicode characters representing those tokens,
then use the regex engine to do most of the parsing work?
I don't know. I'm not convinced that writing the compiler in Perl would
work in practice, but it does seem worth exploring...
Deven
