Re: Revised straw proposal for heuristic info

[William D Clinger <will@ccs.neu.edu>]

Two people (one privately) have pointed out an oversight in
my description of PROCEDURE-ARITY: the integers in a list
should not be required to be exact.  Here is a correction:

(procedure-arity _proc_)

  Returns information about the arity of _proc_.  If the result
  is #F, then no information is available.  If the result
  is an exact non-negative integer k, then _proc_ requires
  exactly k arguments.  If the result is an inexact non-negative
  integer n, then _proc_ requires n or more arguments.  If the
  result is a pair, then it is a list of non-negative integers,
  each of which indicates a number of arguments that will be
  accepted by _proc_; the list is not necessarily exhaustive.

In the rest of this message I will respond to some points
raised by Kent Dybvig.

> I prefer encoding "n or more arguments" as (- -1 n), e.g., 0 or more is
> -1, 1 or more is -2, etc., since this encoding does not presume support
> for both exact and inexact numbers.

I considered this but it seemed a little too random.  This
encoding does not conflict with the encoding above, however,
so we could specify an interpretation for both if that's what
people would like.

> Also, I think that using inexact
> numbers for this purpose is misleading even if it is cute.

I do not see why inexact numbers are any more misleading than
encoding "2 or more" as -3.

> Procedure expression do not necessarily begin with an open parenthesis
> in all implementations.  I suggest simply eliminating "the opening
> parenthesis of".

All lambda expressions begin with an open parenthesis.
Implementations that have extended the language by adding some
other kind of expression that can serve as the source code for
a procedure can of course do their own thing with PROCEDURE-ARITY.
Unless more than one implementation has made the same extension,
there is no point to changing the description of PROCEDURE-ARITY
to deal with it.

Or are you merely concerned about some implementations' use of an
illegal character as a synonym for left parenthesis?

Concerning PROCEDURE-EXPRESSION:

> Source-level procedure expressions are not necessarily represented as
> lists in all implementations.  (They may be after expansion.)  I
> suggest replacing "as a list" with "as a datum".

The revised straw proposal allows a non-list to be returned, but
does not specify how it should be interpreted.  Unless there are
two or more implementations that use a compatible non-list
representation that could be returned by PROCEDURE-EXPRESSION,
I don't see any point to mentioning this possibility.

> Also, the text should
> specify whether the expression is source-level or post-expansion, or it
> should explicitly leave this unspecified.

I'd prefer to leave this unspecified.  I have no problem with
leaving it explicitly unspecified, but that seems like an editing
issue to me.

Will