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.
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