Finally, a traversal can also be any ELisp function, including a lambda defined inline.
Such a lambda would be called with two arguments — the same two used by any traversal — a specification of the computation to be performed, and the in-progress accumulated result. It is expected to synthesize its result with the accumulated result to return a valid traversal result in the context of the containing computation.
In practice, using a lambda as a traversal will never be done, except when defining conditions for use in conditional traversals like decision or precaution. In such cases, use of a lambda is common. Here, as the result of the traversal is only conditioned upon and isn’t integrated into the containing traversal, the only thing relevant to the execution of the traversal is that the lambda return a truthy value on whatever it considers to be “success,” and nil, otherwise. It must, however, still accept the two standard arguments, even if it doesn’t use them.
If you find yourself writing a lambda for any other purpose than as a condition, it would be advisable to discern whether your need for this lambda suggests the addition of a new form to the DSL that would make your lambda unnecessary, so please consider contributing an issue describing your use case.
"If we are somewhere before a previously stored position in the buffer, then go forward, otherwise don’t move."
(symex-eval
(symex-traversal
(if (lambda (_computation _result)
(< (point) previously-stored-position))
(move forward)
symex--move-zero)))