As the others have answered, "lambda" being a reference to "callback", but not limited to that. It's also a reference to techniques from functional languages (currying, map/filter/folds) that also apply to the module.
An example. lambda {} is a (lightweight) object capable of holding the state for you (like monads do), so the following (deliberatly simiplified) construct
lambda {
read {
sysread(...)
write {
syswrite(...)
}}
}
makes sure that a socket handle will only receive writing (and only writing) events after reading events were received.
With this approach, other functional tricks can be done, f.ex. a map analog will make sure that all lambda objects (connections, states) execute sequentially:
print mapcar( lambda { 1 + shift })-> wait(1..5);
23456
where instead "1 + shift" there could be a full-fledged http connection, for example, or a DBI statement, or lock waiting procedure - all non-blocking, of course.
So again, back to the question, it's mainly "lambda" because it shares some interesting hacks with functional programming. | [reply] [Watch: Dir/Any] [d/l] [select] |
| [reply] [Watch: Dir/Any] |
Yeah - actually I did make that mental link - I am just not sure how that applies to the library. But after reading the other post (mentioning callback) I must admit that yeah - it was quite obvious.
| [reply] [Watch: Dir/Any] |