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

Re: implementation strategy (was Re: Working Group Proposal)

Thread Previous | Thread Next
From:
Brock
Date:
July 20, 2000 11:54
Subject:
Re: implementation strategy (was Re: Working Group Proposal)
Message ID:
Pine.SOL.4.10.10007201145180.3141-100000@k2.llnl.gov


On Thu, 20 Jul 2000, Clifford Hammerschmidt wrote:

> 
> Rather than building application X in language A build an application Y in a
> very portable language B that will generate platform specific optimized
> code in language A to build application X.
> 
> eg:
> Write Y in B (write Perl6 builder in Perl5)
> Y writes X in A (Perl6 builder writes Perl6 in C++)
> 
> This is great, since when I've done this in the past with simpler
> projects it's greatly reduced the amount of bugs in the final
> application and made debugging easier all around.
> 
> What I'm advocating is another level of indirection:
> 
> Write a meta-language interpreter in Perl5 that works off extensions.
> Write extensions that build up the meta-language.
> Use the meta-language interpreter to write Perl6
> Have the interpreter output the C++ code for Perl6
> 
> This would make extending Perl6 code much easier for embedded
> platforms since they could modify the meta-language to include only
> what they need, and build custom meta-language extensions
> to handle oddities of the embedded system.
> 
> It also forces your code to orientate around building the meta-language
> and not just outputting C++ code to do X.
> 

How about this idea:

First, we create a perl6 parser, for now written in perl5. It would be
written using the common parts of the language, the parts that we don't
intend to change in perl6.

This parser would output a Parse Tree, which could then be traversed.
Traversal could be done either in perl, or in the proposed meta-language,
though I'd prefer a perl solution.

The traverser could then output the target language. I think there should
be at least two (maybe three) target languages that are always maintained,
C being one of them... perhaps Perl(6) itself being another.

As all of you bootstrappers know, once we got this going well enough, we
could re-compile the parser and traverser using the parser and traverser,
and wham we got C (and others) code for Perl6.

But anyway, the point is that maybe we should consider outputting more
than just one backend language... this would really increase portability,
and if there are two maintained ones then it will make others much easier
to add, if one so desired. Of course the downfall would be more work on
our part.

Am I way off?

--Brock



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About