Thank you for the thoughtful proposal, Kent.  After considering it for
some time, I've concluded it meets all of my requirements and is both
simpler and an improvement over the current specification.  I think it
should be adopted in place of the current SRFI 102 draft, so I will
submit a revision soon.

To respond to the issues you raised:

(1) I am inclined to drop the #f return value to indicate no information
is available.  -1 and #f have the same meaning: it's unknown whether
applying the procedure to any given number of arguments will fail.
Eliminating #f simplifies the proposal and emphasizes the semantics of
`procedure-arity': it only tells you what is not an acceptable number of
arguments; it cannot tell you what is an acceptable number of arguments.

(2) I don't have a strong feeling on the name clash with existing
mechanisms.  Decent Schemes and Scheme standards deal with renaming, so
it strikes me as a non-issue and I'm inclined to leave the name as
`procedure-arity'.

Finally, I just want to say that I do not think procedure arity
inspection should be incorporated into future Scheme standards without a
much more convincing rationale than this SRFI provides.  Basically, I
think the bar for a SRFI has been met: authors have expressed a desire
for such a mechanism and many Schemes provide such mechanisms albeit in
different and incompatible ways.  This shouldn't be sufficient for
something like the Scheme Report.

David

On 11/12/09 8:58 PM, 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
>