Two maybe-bugs and two proposals

[Amir Livne Bar-On <amirlb@xxxxxxxxxx>]

In the question about deriving ordering from equality 
(#node_toc_node_sec_Temp_25), it is claimed that the definition doesn't 
work if there is more than one element. Actually, it would work iff 
thereone exactly one class. Also, in an impure language such is Scheme, 
a comparison function can be defined from equality - but not in O(1) 
operations.

The specification of the chain functions (#node_idx_90) states clearly 
that when exactly one value is given, the comparison function should 
still be invoked. The purpose of this is not clear, since the only 
difference between this comparison and a no-op is type-checking. IMO, 
there is no use for this kind of uniformity here (to me it doesn't seem 
uniform at all).

I would like the <? family of functions to take only one parameter, the 
comparison function, so that they will transform from comparison 
functions to predicates. This is also doable with srfi-26 as (cut <? <> 
<>), but for many uses, including the second proposal, the shorter form 
is nicer.

Another proposal is to drop the `chain' functions. There is one basic 
higher order list function, (chain pred . elts) that applies the elts in 
consecutive pairs. If the previous proposal is also accepted, all that 
would be required from uses is typing (chain (<? comp) ...) instead of 
(chain<? comp ...). It would also allow non-srfi-67 uses of this list 
function, and using default-compare: (chain <? ...) works as (chain<? 
default-compare ...) does in the document.