Re: Revised straw proposal for heuristic info

["R. Kent Dybvig" <dyb@cs.indiana.edu>]

> > Why limit the list in the third case to exact non-negative integers?
> > By doing so, procedure-arity can't precisely describe procedures that
> > accept, for example, 1 or 2+ arguments.

> (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.

Thanks for agreeing to this change.

> > 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.

The problem is that inexact numbers in this context are neither
completely appropriate nor completely random.  In all other contexts,
inexact N means "might be about N, more or less, but who knows?", not
"N or more", and is therefore more likely to mislead people than -1-N
(which is completely random).  "N.0" might even be taken to imply that
the procedure accepts N required and 0 "rest" arguments, since the
"dot" in the middle looks a lot like the dot in an argument list.

> > 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.

Can you give a reason why the change should not be made?  You have
judged my reason for making the change insufficient, but while
insufficient reason to change may be sufficient reason not to change
when applied to items that have already been formalized in print, it is
not for proposals that are still being fleshed out.

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

Actually, I was thinking of identifier macros that expand into lambda
expressions, but you raise a good point.  In at least two Scheme
systems, a open bracket may be used in place of an open parenthesis,
but an open bracket is not a synonym for an open parenthesis, since it
must be matched by a close bracket, not a close 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.

Again, can you give a reason why the change should not be made?

Kent