Add tests for <

[dgr]

Closes #119

[dgr]

Another CLR failure:

FAIL in (test-<) (:0)
negative tests
expected: (thrown? Exception (< "1" "2"))
  actual: nil

@E-A-Griffin, thoughts?

[E-A-Griffin]

ClojureCLR seems to convert strings and chars to longs for inequality operators. I peeked at the ClojureCLR source code and messed around in the repl for a bit but I think this is worth tagging @dmiller

$ cljr
Clojure core loaded in 176 milliseconds.
Clojure 1.12.2
user=> (< "1" "2")
true
user=> (< "2" "1")
false
user=> (< \1 \2)
true
user=> (< \2 \1)
false
user=> (< #"1" #"2")
Execution error (InvalidCastException) at System.Runtime.CompilerServices.CastHelpers/ChkCast_Helper (NO_FILE:0).
Unable to cast object of type 'System.Text.RegularExpressions.Regex' to type 'System.IConvertible'.
user=> (. clojure.lang.Numbers (lt "1" "2"))
true

[dmiller]

This is an interesting problem. The root cause is that Java has a Number class and the JVM does not. I had to do a bunch of workarounds in clojure.lang.Numbers to deal with the mismatch. And this results in an overgeneralization. Where you have parameters of type Number on the JVM, I have to type them as Object. That allows many things to slip into the internal machinery. At some point they will get converted. True numeric primitives are dealt with in their own manner. For numeric types that are not primitive -- think of BigDecimal -- I call methods on the Convert class, such Convert.ToInt64. For this, the value being converted must support the System.IConvertible interface. BigDecimal does. Unfortunately, so does System.String. So if the string argument can be converted to a long, it will fly. (The actual conversion are encoded in methods such as clojure.lang.Util.ConvertoLong.)

I coded this way because (1) I didn't have the Number type to help out, (2) it gave me the extension to BigInteger and BigDecimal (both of which were written by me), and didn't tie me to a fixed set of types -- I had no idea what else might get added in. Unfortunately, it does over-generalize.

The only solution to this over-generalization is to restrict the set of types considered. This could be done by using more restricted versions of Util.ConvertToLong and kin to use in Numbers. This could also be done by directly modifying the definitions of Util.Convert.ToLong and kin. Util.ConvertToLong has something like 46 references. And some of those are to functions used in core. Either is a potentially breaking change, though to a coding practice that should not have been relied on.

What's the right solution? Live with over-generalization? Potentially break code?

[dgr]

@dmiller , I can't advise you one way or another as to the "right solution." My role is just to highlight where I find differences between implementations and then highlight those to the various implementers. This is an area where there are some definite differences across multiple implementations.

The CLJS guys, for instance, delegate a lot of functionality straight to the JS runtime and JS does some weird things with some parameters. When I ask questions of the CLJS devs of the form, "Do you want it to work like this?" often the answer is "We delegate to the runtime for speed and that's how JS behaves." Since these oddities are often for cases that are "odd" to begin with (e.g., negative testing with strange parameters that wouldn't otherwise make sense), we let them go as they are. And then sometimes I find something and folks say, "Oh! Yea. That's a bug." I think you have more flexibility than they do, because the CLR is not an insane runtime like the JS runtime is.

So, the call is yours to make. Just let me know and I can either conditionalize the test in the test suite to CLJR's behavior and make it pass, or I can leave it as is and you can update your side.

I would note that since this is in an area where Clojure JVM throws, it's unlikely that you have too many users that are relying on the CLJR behavior. And it goes without saying that if you are going to make a change, sooner is better than later.

[dmiller]

The question, though not rhetorical, is something only I can answer. But I'm always interested in other viewpoints. So thanks. I guess my overall feeling is that an error of the type where we accept more argument types than one would expect, particularly when based on a platform standard such as System.Convert, is not something I'm going to lose sleep over. I'd feel worse about a breaking change. So I guess I'm going to go with "conditionalize the test".

…

On Mon, Nov 24, 2025 at 9:19 AM Dave Roberts ***@***.***> wrote: *dgr* left a comment (jank-lang/clojure-test-suite#820) <#820 (comment)> @dmiller <https://github.com/dmiller> , I can't advise you one way or another as to the "right solution." My role is just to highlight where I find differences between implementations and then highlight those to the various implementers. This is an area where there are some definite differences across multiple implementations. The CLJS guys, for instance, delegate a lot of functionality straight to the JS runtime and JS does some weird things with some parameters. When I ask questions of the CLJS devs of the form, "Do you want it to work like this?" often the answer is "We delegate to the runtime for speed and that's how JS behaves." Since these oddities are often for cases that are "odd" to begin with (e.g., negative testing with strange parameters that wouldn't otherwise make sense), we let them go as they are. And then sometimes I find something and folks say, "Oh! Yea. That's a bug." I think you have more flexibility than they do, because the CLR is not an insane runtime like the JS runtime is. So, the call is yours to make. Just let me know and I can either conditionalize the test in the test suite to CLJR's behavior and make it pass, or I can leave it as is and you can update your side. I would note that since this is in an area where Clojure JVM throws, it's unlikely that you have too many users that are relying on the CLJR behavior. — Reply to this email directly, view it on GitHub <#820 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAUVZMRM2IR2VAMVDMVJSD36MHXJAVCNFSM6AAAAACM7CM2H6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNZRGAYTQNZTHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dgr]

OK, noted.

[dgr]

Done.

Side question: what's the best way to set up a CLJR environment for local testing on a Mac? Ideally, I could catch these CLR differences before I create PR and let CI run.

[E-A-Griffin]

I'm on a mac, I'd suggest just installing dotnet via brew then installing and using cljr via dotnet tool install cljr, iirc

[jeaye]

Agreed with, you, David. This feels like something which is worth documenting, but not worth breaking.

Thanks for the collaboration, folks. 🙂

[dmiller]

Agree with Mac setup suggestion, from what I've been told.

…

On Mon, Nov 24, 2025 at 2:05 PM Emma Griffin ***@***.***> wrote: *E-A-Griffin* left a comment (jank-lang/clojure-test-suite#820) <#820 (comment)> I'm on a mac, I'd suggest just installing dotnet via brew then installing and using cljr via dotnet tool install cljr, iirc — Reply to this email directly, view it on GitHub <#820 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAUVZLAT6C5BQ3HSEXDD5L36NJHRAVCNFSM6AAAAACM7CM2H6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNZSGI4DQMRRG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>