Re: specific plan

Front page | perl.bootstrap | Postings from July 2000

From:

Joshua N Pritikin

Date:

July 21, 2000 05:33

Subject:

Re: specific plan

Message ID:

20000721083346.D28285@ghostwheel.wks.na.deuba.com

On Thu, Jul 20, 2000 at 07:42:11PM -0400, kfox@vulpes.com 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");
> }
> EOF

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
abstraction:

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)