Yes, you're right, even though callback to grep is indeed a predicate in logical sense, the others are not. That's why I'm saying that IO::Lambda use of the word does not correlate with its use neither in logical/mathematical, nor in programming domains. Also, in IO::Lambda not callbacks, but functions accepting these callbacks are called predicates, which furthers the semantic distance between the word and its expected meaning even more. I wish there would be an established term describing such a functionality, but I don't know any. I was forced for devise a word for it, but as much as I dislike making up new words, and I know that it's sometimes acceptable to redefine an existing word, I chose "predicate", which I think gets closest to the definition of "function with perl signature (&), that accepts a callback on perl stack and parameters on the context stack, executes the callback when the event associated with function, and defined by parameter passed on context, is completed". The same concerns are valid for "lambda": there are no one-word terms for "lightweight FSM generator object tied with anonymous subroutine", except possibly "a monad", but people run away screaming from that word :)
In common use, if I'm not mistaken, I'm not a native speaker, predicates can be thought as constructs (words, sentences) answering questions "if?" and sometimes "when?", f.ex. "we'll talk when you come back", also assuming that we won't talk if you won't come back. In this sense, one can think of, say, predicate "read" in the same fashion: the callback will be called when a socket becomes readable, but it won't be called if the socket never becomes readable.
Nevertheless, I'm open to renaming "predicate" into something more appropriate. | [reply] |
