One for the Perl gurus here. I have an embedded Perl, for the usual reasons, and there are a couple of things I think could be more elegantly done. So ...

1. I have an object that exposes some callback methods, for example:
   
   $x = $Callback->GetFieldName(2);
   
   To create this object and expose it to the script, I actually inject some code at the start of the script:
   
   $CallBack = new Callback(<actual address of external object here>); 
   
   I'm sure there must a cleaner way that doesn't involve modifying the passed script. How can I tell Perl about an external interface in such a way as to leave the above calling convention working?


2. I want to set $_ at the start of processing, because the simplest script should be something as simple as
   
   reverse;
   
   the input being $_ at the beginning, and $_ becoming the output at the end. I currently inject code (immediately after the code that creates the callback object above) that uses a method on that callback:
   
   $_ = $Callback->GetInput();
   
   I'm successfully retrieving  $_ by using
   
   sv = GvSV(Interpreter->Idefgv);
   
   at the end - but my previous use of
   
   SV * defval = GvSV(m_Interpreter->Idefgv);
   sv_setpv(defval, Input);
   
   fails horribly on SUSE 10.2 built using gcc.
   
3. If perl_parse() fails, how do I find the reason and line number of the error(s) in the source? (I'm sure I'm missing something obvious.)

Some more outline - this is a layer between Java and Perl, the embedded interpreter must persist between calls (so there's a parse/execute/execute cycle), there's no guarantee it's on the same thread each time (hey, Java), there may be multiple simultaneous interpreters because execution of one script may cause another to be called, etc.. And oh yes, it's multi-platform, currently working on VC6/Win32, gcc/Win32 and gcc/SUSE combinations, with gcc/AIX being the next to do.

Oh, and yes, there are tens of thousands of lines of existing scripts which rely on the existing behaviour, going back quite a few years, which our new spiffy Java solution must address ... enough with the buzzword bingo.