[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposing a simpler mechanism
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.
> 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.
> 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.