Re: Multiple values for R4RS.

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

	There is an analogy that I'm surprised you don't see: :-)
	
	Just because (pair? x) is #t, I can't guarantee that (cddr x) won't
	error.

Ah, but I can ask (and (pair? x) (pair? (cdr x))), and if this is #t,
then I can be certain that (cddr x) won't error.
	
	Similarly, just because (accepts? p 3) evaluates to #t I can't guarantee
	that (accepts? cons 3) even if
	
	(define (p . args)
	  (apply cons args))

That's right.
	
	Further processing after initial invocation is not guaranteed to be
	correct.  It depends on exactly what the program does.

Right again.
	
	Your argument seems to be that ACCEPTS? is an ill-defined concept ...

My argument is that "accepts?" is virtually meaningless, since it is
a superficial property of the outermost level of the procedure, and there
is no way to extend it further in.  If "accepts?" returns #t, so what?
	
	Again, if you don't try to make it transitive, and a Turing oracle, it
	is perfectly well defined whether a given procedure object accepts a
	given number of arguments or not.  I would be very annoyed (and
	consider the implementation to be in error) if 
	
	(accepts? p 3) -> #t
	
	and then
	
	(p 'a 'b 'c) -> Error from apply: Too many (or few) arguments to p

But this is exactly what may happen if "p" does its own checking, i.e.,
if I write p as:

    (lambda args
       (if (> (length args) 2)
           (error 'apply "Too many (or few) arguments to p")
           (f args)))

Of course, "p" is representing itself as "apply" in the error message,
but I hardly see that it's relevant where the message comes from.