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

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

From:
Clifford Hammerschmidt
Date:
July 20, 2000 11:13
Subject:
Re: implementation strategy (was Re: Working Group Proposal)
Message ID:
4.3.2.7.2.20000720104228.01d45130@mail.marketingtips.com
At 12:36 PM 7/20/2000 -0400, Joshua N Pritikin wrote:
> > Build a meta-language system using Perl5 that allows
> > you to define a new language. The output of the system
> > would be C++ code that implements the new langauge.
>
>It doesn't have to be so formalized.  The "meta-language" could be a mix
>of perl5 and configuration files, or a group of domain specific
>languages.

It would help to formalize it, since I'm assuming there will be
hundreds of people working on the development.

It seems that many people are suggesting using Perl5 as the
language to write the C/C++/etc. code for Perl6, I think building
a language construction language would work better in the long
run.


> > The reasons for going with C++:
> > - Portable across many platforms
> > - Standard Template Library
> > - Large community of programmers
> > - Feature rich
>
>I'm not sure whether these advantages hold when using C++ strictly as a
>target for a code generator.  In any case, I don't feel strongly.  It
>should be (relatively) easy to retarget the backend.

True, that target language just has to provide some minimum set of features
as needed by language generation system. I was thinking that for optimization
staying with one language might produce a better end product though.

I think a model like this is what most people seem to be advocating:

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.




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