Here's a different way to think about it that makes the (<) case, as
well as perhaps (< 2 1 "hi"), make sense quite naturally. < is a
procedure that returns #f if any of its arguments is less than or equal
to the preceding argument. Otherwise, it returns #t.
This definition makes the case (< a b) extend quite naturally to (< a b
c ...), as well as to (< a) and (<).
And anyway, what harm does (<) really do? Why do you think that it is
"broken"?
Many functions which expect a list (fold, map) or a number of arguments
(+, *) accept an empty list or no args as degenerate cases, and give
sensible results. When you write a procedure which expects a list or
uses a rest arg, you generally handle the degenerate cases gracefully
(instead of raising an error). Why should < not be the same?
Bill Schottstaedt wrote:
A couple similar cases:
guile> (< 2 1 "hi")
#f
guile> (* 0 "hi")
0
On the (apply < ...) business, I'd rather get an error than have something
broken go by just because "it is prettier". That null list is going to trip
you...
