Email list hosting service & mailing list manager

proposing a simpler mechanism R. Kent Dybvig (13 Nov 2009 03:00 UTC)
Re: proposing a simpler mechanism Thomas Bushnell BSG (13 Nov 2009 04:23 UTC)
Re: proposing a simpler mechanism Taylor R Campbell (13 Nov 2009 04:31 UTC)
Re: proposing a simpler mechanism R. Kent Dybvig (13 Nov 2009 16:22 UTC)
Re: proposing a simpler mechanism Per Bothner (13 Nov 2009 16:56 UTC)
Re: proposing a simpler mechanism Thomas Bushnell BSG (13 Nov 2009 04:54 UTC)
Re: proposing a simpler mechanism Alex Queiroz (13 Nov 2009 13:44 UTC)
Re: proposing a simpler mechanism Marc Feeley (13 Nov 2009 14:24 UTC)
Re: proposing a simpler mechanism Thomas Bushnell BSG (13 Nov 2009 18:39 UTC)
Re: proposing a simpler mechanism Thomas Bushnell BSG (13 Nov 2009 18:36 UTC)
Re: proposing a simpler mechanism Alex Queiroz (13 Nov 2009 19:08 UTC)
Re: proposing a simpler mechanism Thomas Bushnell BSG (13 Nov 2009 19:21 UTC)
Re: proposing a simpler mechanism David Van Horn (13 Nov 2009 19:25 UTC)
Re: proposing a simpler mechanism Thomas Bushnell BSG (13 Nov 2009 19:36 UTC)
Re: proposing a simpler mechanism David Van Horn (13 Nov 2009 19:58 UTC)
Re: proposing a simpler mechanism Arthur A. Gleckler (13 Nov 2009 20:25 UTC)
Re: proposing a simpler mechanism David Van Horn (12 Jan 2010 18:51 UTC)

proposing a simpler mechanism R. Kent Dybvig 13 Nov 2009 01:58 UTC

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