[r6rs-discuss] Comparison procedures' number of arguments

[Ken Dickey]

On Saturday 18 October 2008 21:29:53 John Cowan wrote:
> Abdulaziz Ghuloum scripsit:
> > You only need to go back to the description of =, <, >, <=, and >=
> > from the report to figure it out:
> >   "These procedures return #t if their arguments are (respectively):
> > equal, monotonically increasing, monotonically decreasing, monotonically
> > nondecreasing, or monotonically nonincreasing, and #f otherwise. "
>
> Well, I don't know.  That would make =, <=, and => of one argument #t,
> and < and > #f, I suppose, contradicting Ken Dickey's view, who would
> make them all #f.  And it's even less clear about the zero-argument
> cases: considering just (=), where there are zero comparisons to make,
> are we to say that the union of no equalities is true, or is it more
> sensible to make it false?
>
> My view tracks R6RS and indeed all its predecessors back to at least RRRS:
> with fewer than two arguments, these predicates make no sense.

I think that the preferred outcome depends on usage.

There are some languages that define "extra" return values get silently 
dropped, some specify this as an error, some say it is up to the 
implementation to decide ("undefined").

Personally, I think that a mismatch between the expected number of "arguments" 
to a continuation is like a mismatch to the number of arguments to a function 
call -- it should raise an exception to alert the system/programmer that 
there is a problem.  

I see the "less than 2 arguments" comparison case in the same way.  I.e. my 
personal preference is that an exception be raised.   [This is a different 
question than "What would a sensible result be in such a case?".]

Can the argument be made that there is a usage case for arithmetic comparisons 
with less than two arguments which has a sensible result?  Where would this 
lead?


Cheers,
-KenD

"Truth emerges more easily from error than from confusion."   Francis Bacon