Arthur A. Gleckler wrote:
> I would still prefer not to have to construct a first-class object in
> order to ask most questions about arity, and also would prefer not to
> have to do so  much type dispatch on the value returned by
> `procedure-arity'.
>
> How about this?:
>
>   ; Is arity information available for this procedure?
>   (arity-available? procedure) ==> Boolean
>
>   ; Return #t iff procedure accepts k or more arguments.
>   ; It is an error to call this if `arity-available?' would return #f.
>   (arity-at-least? procedure k) ==> Boolean
>
>   ; Return all possible arities for this procedure as a list of
>   ; integers.  If rest arguments are supported, the last number is the
>   ; number of arguments above which all possible arities are allowed.
>   ; In other words, if a procedure accepts either 1 or 5 or more
>   ; arguments, return the list (1 5).  The caller can tell that more
>   ; than 5 arguments would be accepted by calling `(arity-at-least?
>   ; procedure 5)'.
>   ; It is an error to call this if `arity-available?'  would return
>   ; #f.
>   (all-arities procedure) ==> list of non-negative integers
>
>   ; Return #t iff `procedure' would accept `integer' arguments.
>   ; It is an error to call this if `arity-available?' would return #f.
>   (arity-includes? procedure k) ==> Boolean
>
> Each of these procedures returns just one type of value, so no type
> dispatch is necessary.  Also, no allocation is necessary except in the
> `all-arities' case, where it seems unavoidable.

I would like to hear what others think of this proposal.  I am reluctant
to discard an API with such longstanding precedent, but since the
currently proposed API in the SRFI seems expressible in terms of the
above, I would be willing to consider it... given there's a consensus
that this one is preferable.

David