Subject: Re: question on arity
From: "R. Kent Dybvig" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 09 Sep 2009 23:46:20 -0400

Proposals for arity-reporting procedures have been made several times over
the years, dating back to before r5rs.  The first record I have is in the
minutes of the r5rs meeting in June 1992:

  A procedure to determine the arity of an arbitrary procedure's
  value was discussed briefly, without result.

I don't recall whether the proposed procedure was rich enough to handle
all procedures defined using case-lambda (though it would have had it been
standardized) or even if sufficient details were presented to determine
if it could handle all such procedures.

Although you didn't ask for it, I'll give my 2 cents on arity-reporting
procedures, which is that they are useless.  In fact, an arity-reporting
procedure is misleading because it appears to but does not actually
guarantee that an arity error won't occur when a procedure is called with
an arity it is reported to accept.  It's common for a procedure to be a
wrapper for one or more other procedures (for tracing, dispatch, or other
reasons), to take an arbitrary number of arguments, and to apply one of
the wrapped procedures to those arguments.  The effective number of
arguments is that of the wrapped procedure that's actually called, but an
arity-reporting procedure would report the number of arguments of the
wrapping procedure.

Before you use a procedure, you really have to know how many arguments it
takes, their types, the ranges of acceptable values, and of course what it
will and won't do.  An arity-reporting procedure seems like a drop in the
bucket, and it isn't even as useful as it seems at first blush.

A more subtle issue is that the mere existence of an arity-reporting
procedure and the like might discourage people from using wrappers such as
I describe, insidiously reducing a language's expressiveness even as they
seem to increase it.  To patch this problem up, you'll probably want to
add a wrapper-creation procedure, which won't actually solve anything
because (a) it won't handle procedures that dispatch to one of multiple
procedures with different arities, types, etc., and (b) you won't be able
to get everyone to use it (or worse, you might).  It's a slippery slope
that leads inevitably to excessive complexity, static typing, or both.

> Based on the current Chez documentation it looks like the PLT interface 
> could be defined in terms of procedure inspectors and calculating arity 
> by retrieving the source code, but it doesn't appear to provide 
> something like the PLT interface off the shelf.  Was this something that 
> was supported in Chez before and has subsequently gone away?  If not, do 
> you have any ideas about early interfaces that supported case-lambda?

The inspector provides expanded source code from which interfaces can be
derived, but only when generation of inspector information has not been
disabled (as it is when the built-in procedures are defined).  So it is
neither a reliable nor an "out of the box" mechanism for determining a
procedure's (apparent) arity.

Kent