in reply to Re^5: IO::Lambda: call for participation
in thread IO::Lambda: call for participation

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?

Replies are listed 'Best First'.
Re^7: IO::Lambda: call for participation
by zby (Vicar) on Jan 05, 2009 at 22:12 UTC
    Yes - that explains context. Now I also found it in the docs. Initially I was looking in Context - now I see it is described in Predicates.

    I hope you don't mind that I'll ask another question - what is the signature of sleep? The documentation says "sleep($deadline) Executes after $deadline". So here is what I would expect to work:

    sub my_sleep(&) { ( $deadline ) = context; print "sleeping ", $deadline, "seconds\n"; &sleep($deadline); }
    But from the example you gave above (and the other ones in the POD) it seems that actually sleep takes the $deadline from the context and the parameter passed to it is actually a callback - is that right or I am totally confused? What does it do with the passed callback?

    After having written that I read Re^5: IO::Lambda: call for participation - and it partially answers this and again I can see it described in the Predicates section. Somehow I did not notice it at the first reading - maybe I expected the predicates to be really simple mathematical logic predicates.

      Of course I don't mind questions, on the contrary, I'm interested to answer as much as I can, otherwise it won't be clear to me what parts of docs are insufficiently explained. So fire away!

      With sleep, and all the predicates, I see where confusion stems from. All of the predicates accepts parameters on two stacks. The callback itself is the only parameter that is passed using perl stack, and all predicates have (&) signature for exactly that. All the other parameters are passed in the context.

      Back to your question, a signature of sleep. The doc says that it is "sleep($deadline)", and is correct in that regard, because it omits two facts that all predicates a) have perl signature (&) and b) always deal with callbacks, so callbacks were not mentioned too.

      Thus, passing the call as &sleep($deadline) is not correct, but &sleep($_[0]) is. sleep(&) expects the callback in $_[0], and deadline in context[0]. Hope that dissolves the confusion.

      Finally, predicates. It seems that the word has many notions, and can be confusing. I'll need to document that term much more thoroughly, - or even consider another name?

        How about "conditions" instead of "predicates"? Also, at the expense of changing your API, it might be clearer if the functions names themselves were less like perl functions and more intuitively descriptive.

        • read -> readable
        • write -> writeable
        • sleep -> timeout
        • etc

        My thought is that since these aren't actually executed immediately, it would be better to have names that describe the activating condition rather than names that sound like an imperative.

        For documentation, I'd strongly suggest separating the perl signature from the context arguments. E.g.

        read($callback) -- context stack: $filehandle, $deadline = undef

        -xdg

        Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.