In short, context is an alternative stack. Contrary to values on the normal, everyday perl stack, that come and go as subroutines are being called, context is retained within a lambda. Predicates use context instead of the perl stack to receive their parameters. In the following code
context $a, $b, $c;
predicate1 {
predicate2 {
}}
Both predicate1 and predicate2 use values $a, $b, $c from the context, even though predicate2 is called after
code that called predicate1 is finished. That code is identical to the following:
context $a, $b, $c;
predicate1 {
context $a, $b, $c;
predicate2 {
}}
From the architectural point of view, context is syntactic sugar. The same effects can be achieved without using it, but at the price of more complex and/or ugly code. | [reply]
[d/l]
[select] |
What is lacking here as well as in the original docs is how context is used - this only says about how it is created.
| [reply] |
Hmm... I'll answer my best and you please tell me if that answers the question. First, context is accessed as context()
property, in get-style:
my ( $a, $b, $c) = context
and in set-style:
context $a, $b, $c.
When one is concerned only with calling predicate functions, such as tail() or read(), context is usually only set, and is not read. It's not impossible, just unneeded.
However, when one needs to write a custom function, that is on the receiving end of context, then the function needs to read the data passed through context. For example, you need to write a wrapper over IO::Lambda::sleep() that also prints number of seconds to sleep:
sub my_sleep(&)
{
print "sleeping ", context, "seconds\n";
&sleep(shift);
}
And that is about it. If the caller wants to restart the call by
context 5;
my_sleep { again if $again }
then the framework makes sure that 5 is still stored in the context, as my_sleep is called from within again().
Does that answers the question? | [reply]
[d/l]
[select] |
