A IO::Lambda object (a "lambda") is an FSM generator
That is correct.
Lambdas are executed using method calls to the lambda, such as call(), wait(), etc. (as described elsewhere). (In what circumstances would I want to use one method or another?)
That too is correct. You would usually use wait(), or rather even wait(@args), that passes @args to the very first callback associated with lambda (where these are seen as @_), starts the lambda, and waits for its execution. However, call(@args) only stores the arguments, but does nothing about execution. Such pre-initialized lambda
can still be awaited by wait(), which doesn't clear @args if no arguments were passed to it. Basically, $x-> wait(@args) is same as $x-> call(@args)-> wait. Also, wait_any() and wait_all() operate more than on one lambda; these functions do not pass arguments at all.
I also like to juxtapose synchronous and asynchronous ways of executing lambdas. wait() and friends are synchronous. tail() etc functions are asynchronous. There are even pairs that do the same in sync and async modes: wait() and tail(), wait_for_all() and tails(), wait_for_any() and any_tail().
Within the initialization callback, special functions called "predicates" register a callback in response to specific events.
..
Predicate callbacks may also call predicates
These two are also correct.
Some predicates may have side effects in addition to registering an event callback.
I wouldn't call it side effect, I think of it rather as a syntactic sugar. That is because tail(@args) can pass arguments to a lambda, and there's no point in passing arguments to an already running lambda. I agree that it
looks like a side effect when you explicitly don't want to start a lambda that is already finished, but that is what autorestart() method is for.
As for the predicates, as you say, they "just define conditions under which callbacks are to be run". And that is one of the ways to put it, correctly and tersely, without resorting to vocabulary of functional languages. That is though a challenge on its own, to coin simple but understandable descriptions for sophisticated concepts.
Also, explaining what gets returned from running a lambda really needs a lot more explanation and some examples
I see. Result of running a lambda is whatever the last executed callback has returned. This is simple for linear execution, f.ex. if
my $x = lambda {
context 1;
sleep { return 42 }
};
then $x->wait returns 42. Pipelining also works in the similar vein:
my $y = lambda {
context $x;
tail { return @_ }
};
$y-> wait returns 42 too. However, things get interesting when $y waits for $x and $z and $t, where the order of execution is not known. Nevertheless, it is the last result that gets returned.
This uncertainty is partially addressed in tailo(), an "ordered" version of tails(). Where tails() returns results of lambdas in the order of their completion, tailo() keeps the order of the lambdas as they were stored in the context. |