What do you expect procedure-arity to return for a procedure which
accepts any number of arguments?  IEEE +inf?

On Thu, 2009-11-12 at 20:58 -0500, R. Kent Dybvig wrote:
> As David knows, I'm not a big fan of mechanisms to retrieve a procedure's
> arity.  If such a mechanism is going to be standardized, however, as a
> SRFI or in some future report, I'd prefer it be as small, simple, and
> efficient as possible.  I therefore propose the following simpler
> alternative to the mechanism described in the SRFI.  It consists of a
> single procedure, procedure-arity:
>
> --------
> (procedure-arity proc) -> bitmask | #f
>
> Bitmask is an exact integer.  Bit i is set in the two's complement
> representation of bitmask if proc accepts i arguments.  Conversely, bit i
> is reset if proc is certain to reject i arguments.  #f implies no arity
> information is available.
> --------
>
> This simpler proposal satisfies the requirements set forth in the first
> paragraph of the rationale.  It is also straightforwardly implemented
> using any of the mechanisms referenced in paragraph 2 of the rationale.
> It leverages the existing bit testing procedures in R6RS and many non-R6RS
> Scheme implementations, e.g., R6RS bitwise-bit-set?; it works for all
> procedures created by case-lambda; and it is uniquely specified, so there
> is no normalization issue.  For most procedures, the bitmask will be a
> fixnum.  In most implementations, this means computing it requires no
> allocation, and working with arities will be efficient.  Perhaps most
> importantly, the mechanism requires the addition of only one procedure to
> the language, and no data types, is simple to describe, and simple to use.
>
> Discussion:
>
> This simpler proposal does not allow an implementation to expose as much
> of the structure of a procedure's implementation as does the existing
> proposal.  For example:
>
> (procedure-arity (case-lambda [(x y) ---] [x ---]))
>
> might return (2 #(0)) with the existing proposal, where #(0) is an
> arity-at-least object representing zero or more arguments, hinting at the
> structure of the procedure argument.  Meanwhile, the same call returns -1
> with the simpler proposal.
>
> On the other hand, nothing in the existing proposal _requires_ an
> implementation of procedure-arity to expose the structure of the procedure
> argument, so the above call to procedure-arity might simply return #(0),
> or, due to some quirk of its optimized representation of the procedure,
> return, say, (0 1 2 3 4 5 #(4)), where #(4) is an arity-at-least object
> representing four or more arguments.
>
> Thus, I see this neither as a benefit of the existing proposal nor as a
> drawback of the simpler proposal.  It might even be considered a feature
> of the simpler proposal that no more of the internal structure of a
> procedure can be leaked than necessary.
>
> Issues:
>
> It might be better for procedure-arity to return -1 if no arity
> information is available, meaning the procedure might accept any number of
> arguments, just to keep it simple and given that the existence of arity
> information is no guarantee of its accuracy, as discussed in the Caveat
> Emptor section.
>
> A different name can be used to avoid conflict with existing mechanisms.
>
> Kent
>