Damian Conway wrote:
>Rod Adams wrote: > >> However, what if what you're calling a non-Perl Parrot based function? >> Do we disable junctions from playing with non-PurePerl functions? Or do >> we autothread over them? How do we tell if a non-Perl function outputs >> to determine if we should be able to autothread into them or not? > >The non-outputting happens at the output operation, which is *always* in >Parrot (at some level) and presumably is dealt with there.
Certainly all Perl code is Parrot code, at some level. However, I think this is more Patrick's problem than Dan's, and that Patrick is going to need some guideince from
I see it this way:
When perl sees a function call, and one of the arguments is a junction, there are three basic options:
1) If the junction is wrapped up in some larger container, like a slurpy list, pass it on as is.
2) If the function in question is an "outputing" one, throw an exception.
3) autothread over the function.
Consider the following:
$x = 3|4;
$y = fun($x);
sub fun ($x) {
warn "enter: fun($x)\n" if $DEBUG;
$x + 1;
}Which option from above is in effect? I do not think I left any room for the junction to be enclosed in a larger container, so option #1 is out. That leaves #2 and #3.
If we autothread, the C<say> only gets a regular scalar, and is happy, so we could get the dreaded repeated outputs.
If we throw and exception, then we have the case that when debugging is turned off (normal case), there is no output at all, and we now have a very confused library user, wondering why this simple math function is complaining about outputting a junction.
So is there a runtime internal flag, saying "I'm in the middle of autothreading a junction, if I happen across anything wanting to generate output, throw an exception."? That would certainly solve the pure Perl problem. But it starts to break down at the Parrot level.
Now consider the case that above fun() was written in Python, and imported into the perl-space. Constrast that to the CPAN author who refactors a perceived slow part of their module into PIR or even into C, and binding it into Parrot via neo-XS. (I don't follow p6i enough to remember what they call it. Certainly it's better than "neo-XS").
How does the "runtime flag" work in these cases? Does Parrot now have to mark all the subs that _might_ perform some type of output as such, regardless of where that sub came from?
If so, has Dan signed off on this?
If not, how does Patrick resolve whether to autothread or raise exception?
-- Rod Adams
