This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (202)
- # aleph (8)
- # announcements (13)
- # architecture (1)
- # aws (2)
- # beginners (201)
- # boot (1)
- # bristol-clojurians (1)
- # calva (2)
- # cider (23)
- # cljs-dev (22)
- # cljsrn (2)
- # clojure (105)
- # clojure-bangladesh (1)
- # clojure-berlin (8)
- # clojure-dev (104)
- # clojure-europe (3)
- # clojure-italy (5)
- # clojure-losangeles (1)
- # clojure-nl (24)
- # clojure-russia (55)
- # clojure-spec (44)
- # clojure-uk (19)
- # clojurescript (58)
- # component (58)
- # cursive (3)
- # data-science (1)
- # datomic (27)
- # duct (6)
- # events (6)
- # figwheel-main (6)
- # fulcro (15)
- # jobs (3)
- # kaocha (5)
- # luminus (1)
- # music (1)
- # nrepl (2)
- # off-topic (24)
- # onyx (1)
- # pedestal (3)
- # protorepl (8)
- # re-frame (18)
- # reagent (39)
- # reitit (1)
- # remote-jobs (1)
- # ring (15)
- # rum (11)
- # shadow-cljs (5)
- # sql (8)
- # tools-deps (12)
- # vim (7)
I'm starting to try using
::keyword style keywords more, but running into a limitation and wondering if it's a misconception on my part. I tried using the namespace as a prefix on a longer keyword, eg
::more.prefix/name, but that's an "Invalid token". Is there something about the Clojure impl (eg around namespaces or interning?) that would break if that were allowed? Is there a "good idea" that's being enforced here to save me from a "bad idea"? I was hoping it would expand to
user=> (alias 'foo.bar (create-ns 'long.ns.foo.bar)) nil user=> ::foo.bar/quux :long.ns.foo.bar/quux user=>
right, at the usage site. I'm inside the defining namespace and conceptually wanting to "group" some things without creating a whole new ns
::more.prefix/name means "look up
more.prefix as an alias and resolve it (to some namespace) and then construct a keyword with that namespace and
I think what's going on in my mind is that as I imagine these ns-qualified keywords escaping my Clojure system, I want to narrow them to remove ambiguity. In other words, I'm trying to name things so they still make sense with fewer contextual assumptions.
Not much outside Clojure is going to be able to accept qualified keywords... Or am I misunderstanding you?
I guess this line of thought is more about self-documenting keywords for human consumption than machine disambiguation.
If you want an alias, to avoid typing, you can always do this inside your
(alias 'more.prefix (create-ns 'the.ns.more.prefix)) ... ::more.prefix/name ...
interesting compromise. That would let me organize my code into files independently of how I'm organizing my names/concepts.
(there's talk of an easier way to create aliases being added to Clojure at some point but that's what we have right now)
There's no need for the "namespace" portion of a qualified keyword to be an actual namespace with code.
We have several qualified keywords in our code base that do not map to namespaces.
I guess at runtime what separates keywords (ns-qualified or not) from strings is mostly faster equality checks due to interning.
(guessing) Non-repeating relative to some local scope (eg the generator itself, the running process, ....)?
@gfredericks Just means that for the run of the test no two ints produced will be the same.
@mac depends what "for the run of the test" means in this context; is this the generative test that spec does with
spec/check or whatever it is?
I'll probably just end up recommending https://www.youtube.com/watch?v=F4VZPxLZUdA
@robert.mather.rmm Stateful because I cannot imagine being able to guarantee uniqueness without maintaining state.
the standard way to do it would be to write your own generator at the lowest level that encompasses the whole relevant scope of uniqueness
you could take the default generator and
gen/fmap it to something that uniqueifies the ints
an alternative, if you don't care how big the ints are, is to just generate really big integers and not allow them to shrink
(you'd need to take care to make the generator something like uniform-distribution, so it doesn't start small either)