Thank you for your reply.
Ive thought about it and it is really perfectly fine
with me if large parts (or all) of the old perl
interpreter where bundled with Parrot in order to
provide Perl5 compatability on Parrot. If using
existing Perl5 interpretor code saves effort and works
well, but still allows you to achieve Perl5/Perl6
interoperability, go for it. Especially with XS
support, using existing Perl interpretor code could be
helpful and save effort, and provide excellent XS
compatability.
As far as Perl modules that involve a patch to the
Perl intepretor, personally I am not bothered if
something like that doesnt work.
The important things is that standard XS code and all
pure perl5 code be able to run with Parrot, and
accessed from Perl6, and Perl6 modules accessed from
Perl5. When I code in Perl6, I want to be able to
still have access to the rich set of CPAN modules that
I have used with Perl5, and use new Perl6 modules from
my Perl5 programs. This would also allow Perl5 and
Perl6 to share the same module archive and allow all
of the Perl5 modules (that arent patches to the
interpretor) to be accessed from Perl6. There is a
lot of stuff and work in CPAN, and I hope the
diversity and selection of tools found their will
remain. Remember, a module (or feature) that seems
worthless to one person might be essential to another.
As a side note, it might be of interest to you, that
completely seperate interpretors have been bridged
before. Take a look at the Tcl module. It basically
runs the Tcl/Tk and Perl interpretors in the same
process, and allows you to call Tcl/Tk functions from
Perl and vice versa. Execution jumps from one
interpretor to the other, yet each interpretor is
completely seperate. I myself have gotten extensive
use of this module.
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> Milscvaer writes:
> > Running the old Perl5 interpretor and the Parrot
> in the same process
> > is not a great solution, since this would mean
> that there would be two
> > completely seperate interpretor codebases to
> support. A big part of
> > Parrot is to allow several languages to use the
> same interpretor, thus
> > allowing them all to benefit from the same solid
> foundation. It would
> > be quite ridiculous if Perl did not completely
> support a past version
> > of itself on Parrot given we are writing parsers
> for numerous other
> > languages for Parrot (a good idea, indeed, but
> lets make sure Perl5
> > has a Parrot parser too).
>
> All your wishes up to this point in the message will
> come true[1].
> That's what Ponie is designed to do. But the first
> sentence of this
> paragraph is a little unsettling. Ponie runs most
> of the Perl 5
> interpreter in Parrot (it does use as much of Parrot
> as it can), but I
> would still say that it is its own interpreter.
> It's simply not
> possible to run on interpreter B when all the code
> thinks your running
> in A. It's possible some of the time, but in the
> general case it is
> not.
>
> So ponie will be most of Perl 5 running in the same
> process as parrot.
> And that's just the way it is, and there's no way
> around it[2].
>
> Luke
>
> [1] If you replace every time you said "all" with
> 97%. Yeah, I know
> your code depends on all the quirks of Perl 5, etc.,
> etc., but you just
> can't get them all. Modules that involve perl
> source patches simply
> won't work. But then again, those weren't really
> "modules", were they?
>
> [2] Unless you find a way around it and tell us.
>
>
__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
