sort-by with comparator fails

Description

In clojure-clr 1.9 the sort-by with a comparator as third argument fails:

clojure-clr-1.9.0-Release 4.0
user=> (sort-by identity < [0 5 3 6 -1])
(-1 6 0 3 5)
user=> (sort-by identity > [0 5 3 6 -1])
(6 3 0 5 -1)

As you can see the ordering of the orguments is not correct. When you order without a comparator (< or > in this case) it works fine.

If we do the same in Clojure 1.10 for Java we see the correct results:

Clojure 1.10.0
user=> (sort-by identity < [0 5 3 6 -1])
(-1 0 3 5 6)
user=> (sort-by identity > [0 5 3 6 -1])
(6 5 3 0 -1)

Environment

clojure-clr 1.9 and clojure-clr-1.7

Activity

Show:
David Miller
February 23, 2019, 6:28 PM

Keeping CLR semantics of Array.Sort using IComparer, (<0,=0,>0) rather than JVM semantics of using a java.util.Comparator (true/false).

David Miller
January 30, 2019, 11:13 PM

The question is how closely we try to match Java semantics vs translating to CLR.

sort and sort-by are glosses on the underlying array sort method. in the JVM, this uses a java.util.Comparator, which is based on a boolean-returning methods .compare and .equals. That is why any IFn can be used, since all return results can be considered truthy.

In ClojureCLR, I kept this as a gloss on the Array.Sort method, which takes an IComparer, which is a <0, 0 , >0 style comparison. An arbitrary IFn, even <, will not give the desired result.

If one is trying to make code work without translation, then I need to change the semantics, and also no longer use System.Array.Sort – unless I do two comparisons to get -1,0,1 semantics.

On a side note, I'm not sure where an IFn picks up the signature of java.util.Comparator in ClojureJVM.

Declined

Assignee

David Miller

Reporter

import