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

Re: specific plan

Joshua N Pritikin
July 21, 2000 05:33
Re: specific plan
Message ID:
On Thu, Jul 20, 2000 at 07:42:11PM -0400, wrote:
> Joshua N Pritikin wrote:
> > I'm not sure if you're trying to elaborate on my proposal or you're
> > coming up with something completely different.
> Elaborate on how your proposal might work. Sorry if I misunderstood
> you -- consider my proposal something completely different then.
> > > 1. A micro-perl compiler is written in micro-perl.
> > 
> > For the record, I never advocated writing a perl compiler in perl.  I
> > envisioned a three step process:
> > 
> >   perl code generator (in perl) => C/C++ compiler => perl
> Unless you're thinking about something more like:
> print <<'EOF';
> #include <stdio.h>
> main() {
>   printf("hello world\n");
> }

Yes!  But I envision something even more sophisticated than B::CC.

> > I'm not sure whether perl can be implemented in perl.  Even if it can,
> > why bother?
> Because it's a good way to get an implementation with clearly defined
> interfaces and simple structure without a lot of code. For example, I'd
> love to have the Perl 6 parser and resulting parse tree hackable in
> Perl without having to dive into C. IMHO the best way to achieve that is
> to implement the parser in Perl.

Hm hm.  Well, I suppose it could work, but even so, you'd still have to
optimize the heck out of the perl -> C compiler to get good parser
performance.  You're proposal is more ambitious than what I envision.

> I'd also like to never see another line of XS code

I know some folks are discouraged by the CPP macro maze.  Even so, I
suggest that we think very carefully about why the macro maze happened
rather than using it like a scapegoat.  I agree that the macros are
annoying but they also solve a particular set of problems.  Maybe we can
solve the same problems in a more elegant way.

> > > This is a total change in direction from previous work done with Topaz.
> > 
> > Yes, well, my proposal was actually in a very similar direction in
> > comparison with Topaz.
> How's that?

Try thinking about it like this.  Here is a chart of levels of

5  perl6 exactly how the perl6 compiler/interpreter actually works
4  perl6 written in perl5               (*)
3  perl6 written in C++ / Java          (like Topaz)
2  perl6 written in C                   (like perl5 source code)
1  perl6 written in machine language

  (*) I'm not sure how to access libc without some sort of C run-time.

Ideally, we'd like to write down exactly how perl6 works and see our
spec translated into optimized machine language: (5) to (1).  A rough
approximation of this ideal is to write perl6 in C++: (3) to (1).  C++
offers a higher level of abstraction than C so it is closer to the
ideal.  However, a C++ type language brings some disadvantages (as
pointed out in recent messages). So maybe the abstraction gap is simply
too wide for a single language.  My proposal is to use perl5 as a fancy
CPP to generate C code.  This way we can go from level (4) to (2) and
then from (2) to (1).  Make sense?

May the best description of competition prevail.
      (via, but not speaking for Deutsche Bank) Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About