That's a fair point, but frankly, it was just an example of why one might
want to use such a function to find arity of arbitrary callable. In this
example I could also invoke callback with two arguments only if it wants
_at least_ two. I.e.

    (my-foo (lambda (x &optional y) ...)) ==> called back with one argument

but

    (my-foo (lambda (x y) ...)) ==> called back with two arguments

Another usecase is possibility to fail early. I know that's not a popular
concept in Elisp, but I find it very useful. The idea is, when you are
given some value that you use only later, you validate it right away. Thus,
you can give immediate error with explanation rather than letting it fail
in mysterious and hard to understand way in a completely different place
later:

    (defun my-set-termination-callback (callback)
      (unless (and (functionp callback) (>= (car (function-arity callback))
1))
        (error ...))
      (setq my-termination-callback callback))

Paul

On 15 March 2016 at 23:45, Davis Herring <herring@lanl.gov> wrote:

> This way `my-foo' automagically accepts callbacks that expect one argument
>> (as in initial form), as well as those that want two arguments.
>>
>
> What if your existing clients might have
>
> (defun paul-callback (computed-data &optional cached)
>   ...)
>
> where they make calls to `paul-callback' themselves with the extra
> argument?  It's fair to call this "abstruse" (maybe most/all clients just
> use a lambda), but it might also make you think about providing another
> callback interface.
>
> Davis
>
> --
> This product is sold by volume, not by mass.  If it appears too dense or
> too sparse, it is because mass-energy conversion has occurred during
> shipping.
>