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.
It will be great to have a standard interface for such information. Thanks for proposing this. Why are arity objects first class? Does that improve performance dramatically on some implementations? 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.