This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

## 2018-09-25

## Channels

- # beginners (81)
- # cider (53)
- # cljdoc (9)
- # cljs-dev (66)
- # cljsrn (4)
- # clojure (108)
- # clojure-austin (5)
- # clojure-dusseldorf (1)
- # clojure-italy (11)
- # clojure-losangeles (2)
- # clojure-nl (4)
- # clojure-spec (40)
- # clojure-uk (52)
- # clojurescript (64)
- # cursive (131)
- # datomic (27)
- # emacs (13)
- # events (1)
- # fulcro (18)
- # hyperfiddle (10)
- # immutant (2)
- # leiningen (1)
- # liberator (5)
- # luminus (1)
- # nyc (1)
- # off-topic (35)
- # onyx (2)
- # pedestal (52)
- # portkey (5)
- # re-frame (12)
- # reagent (11)
- # shadow-cljs (47)
- # sql (1)
- # tools-deps (5)
- # unrepl (2)
- # figwheel-main (22)
- # 100-days-of-code (3)

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`

.)

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

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

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.

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.

If we moved the `goog.math.Integer`

from `int?`

to `integer?`

that would roughly correspond to making things right

Good point. Really, you'd then need to consider expanding `number?`

, *etc.* and at some point it feels like too much. Hrm.

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

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

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.

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.

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

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?`

@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

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.

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