[r6rs-discuss] Comparison procedures' number of arguments

[Isaac Morland]

Responding to the digest, so various people are quoted below, anonymously 
(which maybe is the best way in a discussion such as this!):

On Fri, 24 Oct 2008, r6rs-discuss-request at lists.r6rs.org wrote:

>> It seems to me that if you accept (and) => #t then you should accept (<)
>> and (< x) => #t.
>
> My old eyes see:
>  (length '(1)) => 1
>  (length '()) => 0
>  (length) => -1
>
> Things can be defined this way, but is it most useful?

Ok, I can no longer resist jumping in.  The suggested definition is 
unlikely to be most useful, but that says nothing about the (<) and 
related cases under discussion.  length takes a single parameter, expected 
to be a list.  The little sequence above is not a natural sequence, so 
inferring a sequence into the procedure results does not make sense.  In 
the first two cases, we have a single parameter, while in the last case we 
have no parameter.  Without some more examples of what you are suggesting 
length might do with more than one parameter, I can't see any pattern.

> I think that in this case, I am just going to express my opinion and we will
> agree to disagree.

I am certain that there is a "programming koan" that would be apropos, but 
I am not enlightened enough to find it.

>> When I look at srfi-32 code [sorting, retracted], SCIP, Scheme and the Art of
>> Programming, Concrete Abstractions, ..., grep for used of (< n) in code
>> [legal in Chez, Gambit, Ikarus -- which disallow (<)] I have not yet found a
>> use of the form (< n).
>
> Just because there are no syntactic occurrences doesn't mean < is not
> applied to zero or one arguments.  I bet similarly you cannot find any
> occurrences of (+) or (+ n).

Exactly.  The value of (<) and friends is not for writing out literally - 
there are easier ways of writing #t.  But when calling it via apply or via 
a macro, one does not expect things to blow up just because, on a 
particular occasion, the incoming list has less than two elements.

> PS FWIW, as a result of the discussion I think there are two consistent
> positions: < takes exactly two arguments, or < takes zero or more
> arguments.  My preference is for the latter.

Agreed; and in the latter case, (<) and (< 5) are both #t.  To me it seems 
obvious that insisting that < take exactly two arguments is unSchemely, 
and I am astonished that this is controversial.  One of the things that I 
first found elegant about Scheme was the fact that procedures can take a 
variable number of arguments, including 0, and the additional fact that 
the standard functions make use of this fact to extend procedures that 
normally take a fixed number of arguments to variable-argument procedures 
in a natural way.  Common programming idioms like "a + b + c + d" and "x<y 
and y<z" can be expressed more clearly and succintly than otherwise. 
Additionally, it felt like Scheme tries to work properly even as one moves 
into base cases and degenerate situations.

I am even more astonished that there has actually been discussion over 
what the value of (<) and (< 5) are, assuming they are permitted.  I don't 
think there can be any useful discussion on this point, as it follows from 
the meaning of a vacuous statement and from what would be expected when 
using apply or writing a macro.  I am not aware of any 
mathematically-aware argument that has been made to the contrary; if one 
has been made, I would appreciate a pointer to that message in the web 
archive.

Next somebody is going to argue that the natural numbers start with 1, or 
that an equilateral right parallelogram is not a rectangle (or better yet 
that an equilateral diamond is not a square!).

> PS I do think there is a case to be made for the usefulness of (<) by
> appealing to similar patterns, like:
>
> (define (sorted? ls) (apply <= ls))
>
> Which will break as <= is currently defined.  [That any empty or
> singleton list is sorted, is in my view widely accepted and
> uncontroversial.  I'm surprised to even hear this questioned.]

Exactly.

Isaac Morland			CSCF Web Guru
DC 2554C, x36650		WWW Software Specialist