This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 100-days-of-code (3)
- # beginners (80)
- # cider (53)
- # cljdoc (9)
- # cljs-dev (66)
- # cljsrn (6)
- # clojure (108)
- # clojure-austin (5)
- # clojure-dusseldorf (1)
- # clojure-italy (9)
- # clojure-losangeles (2)
- # clojure-nl (4)
- # clojure-spec (40)
- # clojure-uk (46)
- # clojurescript (60)
- # cursive (119)
- # datomic (28)
- # emacs (10)
- # events (1)
- # figwheel-main (21)
- # fulcro (16)
- # hyperfiddle (10)
- # immutant (2)
- # leiningen (1)
- # liberator (5)
- # nyc (1)
- # off-topic (36)
- # onyx (4)
- # pedestal (52)
- # portkey (5)
- # re-frame (11)
- # reagent (11)
- # shadow-cljs (46)
- # sql (1)
- # unrepl (2)
Is it just me, or does it seem like we have the
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:
tracked this Clojure change
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
Hrm. For me, I struggle to come up with a simple mental model for the difference between
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
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
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
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:
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
@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
integer? could be revised (maybe if we are careful of the consequences)