@dkubb

 Ducktrap supports `#call` and `#run`:

`#call` returns an Evaluator object. Where you can use `#output` and `#success`?
`#run` uses call internally but raises exceptions when `#success?` is `false`. `#run` is just a convenience method for a "I dont wanna deal with errors, but I wanna have exceptions once it does not work".

In my `morpher` reimplementation of ducktrap:

 I'll also provide `#call` and `#run`. But we'll have a tracing and a nontracing evaluator.  For the tracing one you get that `Evaluator` object on `#call` for both success and error. `#run` will have the same semantics as above.

For non tracing evaluator (you'll use this one in most mapper cases!) `#call` returns the result on success, but raises exception on error. The non tracing evaluator will create NO intermediary objects. I expect optimum performance here. `#run` will be an alias of `#call`.

The tracing evaluator will be build of a non tracing one. So no duplication planned. The nontracing evaluators `#call` will exactly behave like `Proc` `Method` and friends.

BTW: This is NOT written in stone. I'll probably improve this once I do the implementation and see the code.