This page is part of the web mail archives of SRFI 102 from before July 7th, 2015. The new archives for SRFI 102 contain all messages, not just those from before July 7th, 2015.
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