Front page | perl.bootstrap |
Postings from July 2000
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