Is it just me, or does it seem like we have the int? and integer? predicates backwards from what they mean in Clojure?

Why do I say this? - The subset relations are backwards. - The arbitrary- vs. fixed-precision aspect seems a little backwards.

Oh, here is what I think happened: This change https://github.com/clojure/clojurescript/commit/bcf60ce194e5292fbc5c4b2d89dfc5a7b886b94c tracked this Clojure change https://github.com/clojure/clojure/commit/20f67081b7654e44e960defb1e4e491c3a0c2c8b Note the commit title "rename long preds to int and cover all fixed precision integer types" It was probably an oversight that goog.math.Integer is not fixed-precision.

(It is super easy inadvertently draw an incorrect parallel between java.lang.Long : java.lang.Integer and goog.math.Long : goog.math.Integer.)

Or maybe this was intentional as the docstrings were not copied verbatim

Hrm. For me, I struggle to come up with a simple mental model for the difference between int? and integer? that spans both dialects. That's why I was digging into this.

Here's a mental model that may work: integer?: Things that are number? but are "whole" int? (and friends) : Things that work well with spec. (I'd still be a little hard-pressed to explain goog.math.Integer)

conceptually, I’d say integer? = all integers, int? = integers representable as fixed precision integers

Yeah, OK. Maybe the goog.math.Integer inclusion was a mistake.

goog.math.Integer seems like it is a subset of int?

it really matches Java int right?

goog.math.Integer is like BigInt

Google picked a really bad name for that one.

oh, I see after reading more closely

yeah, I’d say that’s integer?

Right, you seem to be where I started at the top 🙂

int? = host primitive integer?

Rather, a non-fractional real number represents me using a host’s primitive value type for numbers

*represented using

Dang. I feel like this may all be water under the bridge, given this stuff's been in since 2016. Unless you could weasel an argument that these predicates were introduced with spec, which is still alpha. Ugh.

We may be stuck with things.

Or... you could play the card that, this is just a bug. We need to fix it.

If it helps, I am continually confused by Clojure’s numeric predicates

I do like integer? is ℤ and int? is a fixed-precision subset of ℤ.

Fixed precision by type or value?

Fixed- as opposed to arbitrary-precision, which is needed to represent ℤ.

“Fixed precision” meaning “fits in a long/double”? Or within some range

Good question. If I had to defined "fixed-precision integer" I'd be happy a 2's complement representation that has a fixed number of bits.

Yeah cljs just broken

Sorry

It’s backwards

If we moved the goog.math.Integer from int? to integer? that would roughly correspond to making things right

That parsefloat check is also really strange

Long as well

Good point. Really, you'd then need to consider expanding number?, etc. and at some point it feels like too much. Hrm.

In Java, the type and value spaces line up better

Because there wasn’t clarity about what it means when they differ, cljs is all over the place

Perhaps in a few years we will be struggling to find a way to fit js/BigInt into ClojureScript. Maybe that'd be an opportunity to tackle consequences for number? etc., but all of that feels like breaking change

Cljs integer? For eg accepts a bigger range than js

Even outside the range of safe arithmetic

For now, maybe a small step would be to remove the arbitrary-precision type (`goog.math.Integer`) from int? (and friends) and change the docstrings for int? and friends to match Clojure's

Slack autocomplete is a bear

(By friends, I mean pos-int? neg-int?, nat-int? etc.)

I really think there is a good chance we got mistaken by goog.math.Integer looking too much like java.lang.Integer. I'm probably guilty of that mistake back in 2016 when that changeset went it. I recall looking at it at the time and I even think I recall making that mistake.

Even though it would strictly be a breaking change to remove goog.math.Integer from int?, I'd actually be surprised if any code has even become dependent upon that aspect.

Don’t you have to s/int/integer?

If following clj Cljs int should accept non-fractional double and goog Long

And integer? All int? Plus goog Integer

Yeah, to really make ClojureScript follow Clojure you'd need to make a lot of drastic changes. You'd need to consider revising number? as well.

In Clojure this is a chain smaller and smaller subsets: number?, integer?, int?, nat-int? In ClojureScript, when you hit int? the set gets bigger.

@mfikes I’d say bug - and see what the feedback is

I’d be surprised if a lot of people are relying on these semantics, we bottom out in JS after all

Ok, I’ll write a JIRA, at least removing goog.math.Integer from int? and friends

If we also removed goog.math.Long, that would fix more of it in that you can’t have something that satisfies int? without it also satisfying integer? and number?

Maybe that second choice is better…

let’s get this all collected in JIRA for review

Cool. Yeah—that’s better. Will do.

@mfikes re the inference stuff, have you checked the perf? At least initial hunch is I would be surprised if much slower - since it’s not really inner loop stuff like the recent optimizations

re: goog.math.Long why should that not be true for number? and integer?

One patch (the and/or/if stuff) is currently slowing things down by 10%, and the return-type inference ticket for variadic and multi-arity fns is adding a 5% slowdown.

hrm ok

We might succeed in squeezing the perf for those still…

So opting into type inference could be a thing, but maybe we can avoid that and keep things simple

Yes, number? and integer? could be revised (maybe if we are careful of the consequences)

^ https://dev.clojure.org/jira/browse/CLJS-2921

thanks