inconsistent definition of "sort" (and what about stability?)

On Sat, Nov 19, 2011 at 07:37:29PM -0800, Steve Haflich wrote:
> Stavros Macrakis <macrakis at alum.mit.edu> wrote:
> 
>    If P(a,b) is not true or false for some a and b, sort signals an error.
>    
> >From where do you infer this behavior?  It is _not_ something about
> cl:stable-sort guaranteed by the ANS (assuming the Maxima call to sort
> has not been rewitten to wrap the predicate to test for this).
> 
> On the other hand, in ANSI CL there are no possible objects which are
> neither "true" nor "false", in the sense of "generalized boolean" which
> is what the sort predicate is required to return.  Therefore the
> provision would be meaningless.
>   

If I understand you correctly, then everything would be implicitly
converted by ANSI CL into a boolean, however we get

(%i1) sort([1,2],lambda([x,y],7));
Unable to evaluate predicate 7

So it seems sensible to me to require that the predicate must always
return "true" or "false".

However, as stated in my other e-mail, I agree with not to specify
what happens if the predicate is not "good".
 
>    On Sat, Nov 19, 2011 at 20:28, Oliver Kullmann <O.Kullmann at swansea.ac.uk> wrote:
>    
>        Predicate should return true if and only if the first argument is
>        strictly less than the second (in some appropriate sense).
>       
>        (It's sloppy in the sense that "appropriate sense" it not defined.)
> 
> "Appropriate sense" here means that sort predicate determines the
> desired ordering.

"determines" in what sense?

> That sense is opaque to and of no concern to sort
> itself.

As I interprete it in my other e-mail (to Stavros), that
would say "use anything which happens to work with the algorithm",
and that would depend on the implementation of sort.
As I propose in my other e-mail, I think using the common
understanding of sorting and its prerequisites would be best.

Oliver