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, [EMAIL PROTECTED] 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 _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
