Rich Morin writes:
> In any case, one way of doing something like this in Perl might
> be to have the ability to register exceptions for a range of
> quite ordinary behavior, such as entering or leaving a statement,
> setting or even accessing a variable, etc.
Or passing a variable to a function. This is sort of a hot topic in my
brain right now. It turns out that Junctions cover some of the same
ground as your hooks want to.
I definitely want such hooks.
You can do it easily at compile time with a grammar munge that munges no
grammar:
grammar DebugPerl is Perl {
rule statement {
{ Parrot::emit "enter_hook()" }
<super> # call Perl::statement
{ Parrot::emit "exit_hook()" }
}
}
use grammar DebugPerl;
For certain values of enter_hook() and exit_hook().
But another thing that would be nice is to track a value to see where
it's being used/changed. Better yet, to implement a module that makes
use of that tracking ability to do some magick.
Don't mind if I digress from your question a bit now. For large values
of "a bit".
I've been thinking of an Operator type class that represents "something
to be done". Operatable variables would get a hook called with the
operator as an argument instead of doing something. Junctions are
pretty easy if you do that:
multi sub OVERLOAD (Conjunction $j: Operator $o) {
map { $o.($_) } $j.states;
}
multi sub OVERLOAD (Conjunction $j: Operator::Boolify $o) {
for ($j.states) {
$_ or return;
}
return 1;
}
And it opens up a huge field of junction-like things that you can do,
never before possible. It's like a super-powerful tie.
The question is: how do you catch these naughty values in the act? If
we marked variables that could hold them and were forced to explicitly
type any function that returned them, then it's easy to do with no speed
hit to the unaware.
But we might be able to do better than that (that is, very little speed
hit without syntactic markings).
Whenever a magick value is created, it marks a scope local flag
"NAUGHTYBUSINESS", which is checked before magick hooks. If it's on,
then the sub can branch to a less efficient, more aware version of the
call and proceed from there. But then you still have to check a flag
before your hooks, which puts a limit on how many hooks you can have.
Warning: highly theoretical stuff follows:
A really nice thing to be able to do is to change the implementation of
a sub while it's running, and be able to come back in the middle of the
changed one. It's also a very hard thing to do, and usually deemed
impossible.
But I've been thinking that it's not, in fact, impossible. If the two
subs are the same semantically (that is, you're not coming back saying
that "no I didn't do that" when you already did), and you have details
of both implementations, then it would be possible to make a mapping
from the old implementation's lexical state to the new one's at some
point in the execution. I'm not sure how restrictive the restrictions
would have to be, but I'm sure that it works for at least a few useful
cases.
Did that answer your question? :-p
Luke
