Thanks for the feedback.

Arthur A. Gleckler wrote:
> Why are arity objects first class?  Does that improve performance
> dramatically on some implementations?

It is not for performance, so far as I know.  The current API design is
just based on what I found the be the most widely supported arity
inspection facilities, which has precedents in PLT, Larceny, Gauche and
the Clinger proposal.

> If not, it seems like it complicates the interface without benefit.
> How about this instead?:
>
>   ; Is arity information available for this procedure?
>   (arity-available? procedure) ==> Boolean
>
>   ; Does this procedure have fixed arity?
>   ; It is an error to call this if `arity-available?' would return #f.
>   (fixed-arity? procedure) ==> Boolean
>
>   ; Return the minimum arity of this procedure.
>   ; It is an error to call this if `arity-available?' would return #f.
>   (minimum-arity procedure) ==> non-negative integer
>
>   ; Return #t iff `procedure' would accept `integer' arguments.
>   ; It is an error to call this if `arity-available?' would return #f.
>   (arity-includes? procedure integer) ==> Boolean
>
> This is simpler because I only have to check the return value of
> `arity-available?' before I call any of the other procedures.  I don't
> have to call `procedure-arity', then check both its value and return
> type before I can find out the procedure's minimum arity.

I believe this interface is easily and portably defined in terms of what
the SRFI gives you, however the converse is not true.

One benefit of the current proposal is that it can handle procedures
constructed with `case-lambda'.  Under the above proposal, it's not
possible to produce an error message that says something like:
"procedure f expects 1, 5 or 6 or more arguments, given 2: a, b".

David