Re: Outstanding parrot issues?

Arthur Bergman wrote:
> 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.