I am now going to be impolite.
Meh...
Leo: There are some embedding applications where it's simply not possible to get the top of the stack. For example, let's say I want to write a Parrot::Interp module for Perl 5 (on a non-Ponie core):
my $i=new Parrot::Interp;
my $argv=$i->new_pmc('PerlArray');
$argv->push($i->new_pmc('PerlString')->set_string('foo'));
$i->load_bytecode("foo.pbc");
$i->run_bytecode($argv);Now, theoretically Parrot::Interp::new should capture the top of the C stack, but there's no way it could do so. If it captured an auto variable in its own body, that variable might not even be part of the stack by the time run_bytecode is invoked.
Having said that, the PMC registration technique ought to be good enough for this particular application.
Arthur: Embedding Parrot will never be quite as simple conceptually as embedding Perl. The garbage collection system ensures that. Even so, there does need to be a way to embed Parrot without having it take over your program--and it appears that PMC registration and other alternative methods of dealing with the GC will do that. There's no need to disable the GC outside of a runloop, and in fact I could easily imagine someone using Parrot buffers and the GC system without using the runloop itself as a convenient memory management system for an application otherwise written in straight C. (Not to mention that Parrot I/O and strings should be a lot nicer than the straight C equivalents...)
Parrot must be embeddable in virtually any environment Perl can be. That doesn't mean it has to be as easy, but it has to be possible. If it isn't, we might as well give up on the embedding interface altogether.
-- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Oceania has always been at war with Eastasia.
