Fork me on GitHub

(defmacro uh-oh []
  (let [id (gensym "id")
        m {:id id}]

;; Syntax error compiling at (*cider-repl Code/flex:localhost:50966(clj)*:35:7).
;; Unable to resolve symbol: id20798 in this context
any tricks to emit data with a symbol in it from a macro?


ah I unqoute then quote it


(defmacro uh-oh []
  (let [id (gensym "id")
        m {:id id}]

;; => {:id id20812}


ah but that prevents eval of any of m:

(defmacro uh-oh
  (let [id (gensym "id")
        m {:id id :f f}]

(uh-oh (fn [] "foo"))
;; => {:id id20820, :f (fn [] "foo")}


(defmacro uh-oh []
  (let [id (gensym "id")
        m {:id (list 'quote id)}]
There's several ways to quote the symbol. I find the (list 'quote my-sym) idiom is easiest for me to follow.


aha! thank you


(defmacro foo [] {:id 'id#})`


the backquote is there before the map but it's quite confused the parser


see above why backqouting the whole map doesn't quite work


Is there any guidance on when one should use simple/qualified keywords?


for example { [:timeout vs]}


Or even (s/keys :req [::foo]) :req being simple


My rules of thumb: 1. qualified keywords for extension mechanisms, so that you can register your own stuff under your own namespace and avoid conflicts 2. simple keywords for internal implementation details The argument against qualified keywords is mostly brevity.


I'd love to see seasoned Clojurians like @U064X3EF3 and @U04V70XH6 reply. Ideally, I believe this should be addressed in a rationale on


Perhaps here:


Yeah, I was searching for something like that at first


perhaps this is something for ask clojure


IMHO the higher the probability of name clashing, the more reasons there are to use namespaces. In a controlled environment, like the confines of my own project, I almost exclusively use plain keywords. It also makes reusability much smoother if some entities are similar, like

(defn name-with-description [{:keys [name description]}]
  [:span {:title description} name])
The above can be used everywhere on entities that have :name and optionally :description. But in an uncontrolled environment, like an API, I think namespaced keywords make more sense, especially if it's something extendable.

👍 3

> perhaps this is something for ask clojure I'd give that questions as many upvotes as I can.


Unfortunately, I'm unable to provide more than a single upvote!


It’s a question of: 1. scoping 2. use case


if the scope is the argument to a single function, then an unqualified keyword does no harm and is shorter to type

👍 3

if the use case is, “keys in a hashmap” you always want namespaced keys


if the use case is values in a hashmap, you might want unqualified keywords


e.g. {:http/method :post} is fine


:post in this context is somewhat universal and is never intended as the key in a map, so it cannot clash


On the other hand, if you’re developing a new library with new terms, you might consider a namespace qualifier. {:my/mode :my.mode/fast}


^ does little harm and is slightly easier to use tooling to search for


but the upside is comparatively marginal if :my.mode/fast cannot clash because it’s always a value


Thanks for the input!


A big downside to unqualified is the impact on refactors. We have a large code base. If someone uses an extremely common keyword (e.g., :type), you need to sort through hundreds of uses. It is very likely you'll miss one and potentially break the code in a very nuanced way (yay optional keys).


True, and editors like Cursive and probably other setups too allow refactoring namespaced keywords like vars

✔️ 6

I always wonder why tools.deps does :git/url but then :sha unqualified

Alex Miller (Clojure team)15:03:43

The original idea was to have at least one key qualified so we could determine procurer type, but not the others for conciseness

Alex Miller (Clojure team)15:03:16

In retrospect, that was dumb

Alex Miller (Clojure team)15:03:55

May allow both in the future


Right now I'm designing a task runner "DSL". First I had:

{:task/type :shell (or some other task dispatch key)
 :task/args ...
 ... other task specific opts}
but this was getting too verbose. Since type + args were always there, I could just go with hiccup style:
[:shell { optional opts map } ... args ...]
But because every task can have some general options like :description I didn't want to put those in the task options, so I went with:
^{:description ...} [:shell { optional opts map } ... args ...]
Kind of like docstring meta. But that's also a bit weird maybe. So I'm considering:
[:shell {:task/description ...  other opts } ... args ...]
now where :task/* are general task opts which can never conflict with the other task specific opts because of the namespace... :thinking_face: .

👍 3

Full example:

{:tasks {:clean [:shell "rm" "-rf" "target"]
         :uberjar [:shell "clojure" "-X:uberjar" ":jar" "foo.jar"]
         :all [:do {:task/description "Execute all steps"}

👍 3

It still feels a bit wrong though, to put the :task/description in that spot.


well maybe it's ok, since in HTML you also put "id" etc on random HTML elements of different types


So you'd want to avoid conflicts between :clean, :shell, :uberjar, :do and the like? Some options come predefined (shell, clean, do), others are defined by the user (clean, uberjar)?


Avoid conflicts between options passed to the tasks, e.g.:

[:shell {:task/description ... :shell/opts {...}}]
I don't necessarily want to namespace every single keyword


yes, there is also the issue of user defined clashing with built-ins like :shell, but I don't like [:task/shell ....] [:task/babashka ....] etc, I think


Mhm, it gets too verbose quickly.


instead users can choose namespaced keywords


if there are clashes, or just choose a different name. The user-defined task will always be chosen first, so if they override, they just make something inaccessible for themselves, which is not the end of the world

👍 3

> instead users can choose namespaced keywords That might make sense, especially if one is referring more to the predefined symbols than ones own additions


it's a similar problem with overriding vars with local symbols in clojure


yeah, I was thinking the same thing.


I really like Clojure's namespacing mechanism.


And as long as you allow the user to override definitions, you won't break users if you add new symbols to the default environment



✔️ 3

maybe I should add a way to always refer to the built-in, e.g. :task/shell will always refer to the built-in, no matter if you overrode (?) it with :shell, like clojure.core/name always refers to the built-in var


I've make a mistake of "namespacing everything with too much cruft" before myself. I had just learned about namespaced keywords. I was designing a data interface with EDN, so I just namespaced everything. How did people like it? It was a hassle. Didn't help that I just used ::key-name in my Clojure file, so there were multiple layers in the namespace as well. I don't want to do that mistake again.


> maybe I should add a way to always refer to the built-in I like that idea.


Could make reusing parts of task runner specifications less problematic.


I think using qualified keywords add a lot of leverage in your codebase, as mentioned before, its great for refactoring, but also for understanding the code base, a find usages in a qualified keyword can give you an accurate view about what that property means across the system (and how its being used). For enumerations is also great, in editors like Cursive, instead of going to look up in a documentation about what are the options, if you have something like :my.task.type/foo and :my.task.type/bar, on typing :my.task.type, you can see the options right there


note that dots in the name part of keywords are not officially supported (if you have :my.task.type as a standalone keyword)


I think he meant typing the namespace part will bring up auto-complete


I mean't more as a prefix for auto-complete, not as an actual keyword (the last one)


right, my bad


@U066U8JQJ I'm guessing you're speaking from experience? I'd love to hear examples / instances where qualified keywords have enabled nice workflows.


and also where you'd consider them not necessary.


I do a lot of fully qualified keywords in Pathom for example, and in Pathom I use a more hard-core attribute driven philosophy (and Pathom itself is an expression of this idea), so for example, in the planner ( or runner ( you can see a lot of keyword definitions at start. those keywords are mostly used inside the same namespace, but are not limited to it. so when I need get back on feet in some complex part of the code that I haven't touched in a while, I can see which keywords participate in the process, and by following their usages I can quickly remember all the places in which its used. I believe that having consistent property names (close the same way we regard our functions, as an independent being) enables consistent re-usage of these same keywords, and them their semantics can flow over the system

💯 3

about short keywords, I do use them as well, but I try to avoid most of the time

👍 3

Thanks for explaining!


hope it makes sense, I'm deep in this rabbit hole :P


(>def ::node-id "docstring" pos-int?)
i'm guessing does: 1. Document the "attribute" 2. "establish it" (don't use not-established qualified namespaces) 3. specs the value ?


correct, I'm using Guardrails, which is some syntax on top of spec, this doc is purely for the code reader (you can't access it at runtime)

👍 3

I wasn't aware of that, not sure why its on deprecate list (@U0CKQ19AQ maintains Guardrails), gotta understand why

👍 3
🤞 3

For the record, I've spent enough time guessing what "name" can actually be for JSON documents in codebases to be curious about a better way.


@U08BJGV6E sorry for derailing your thread 😅


This is the sort of discussion I was hoping for 😄

😊 3

I might link this thread into the askclojure once it's available in the log

👍 3

@U3X7174KS on your "name", issue, that's a great case to start seeing it, unqualified names always require some context to understand, but a lot of times this context is implicit, and then its up for the reader to interpret it. being fare, its easy in a lot of cases, but the worst is when you are confident, but wrong at the same time. this is the kind of problem qualified keywords can eliminate, if they are big enough (same considerations as for functions), you can always be confident about their meaning, no need to know the context

👍 6

but its a hard battle, JSON dominates everything, and I find unlikely that the industry is changing in that direction anytime soon, so for those wanting this path, there is a lot of "naming expansion" to be done while interacting with external sources of data, but I believe in Clojure world we are much closer, and we could have a nice ecosystem of qualified names here

👍 6

FWIW JSON totally accepts "foo/bar" keys


GraphQL however, maybe not, I found their support for these kinds of things lacking in some respects when I checked it out some years ago. A step back from RDF.

☝️ 6
😭 3

The whole "hard-core attribute driven philosophy" makes a ton of sense to me when I hear people talk about it but then I do tend to struggle with how exactly to implement it when I sit down to code something. Thus I can never get enough of these kinds of discussions 🙂


My general conventions here are informed by a lot of re-frame use and Clojurescript having weaker support for namespace aliasing: 1. Internal to a namespace: unqualified generally 2. If it’s being shared out (eg. a re-frame handler key) then it gets namespaced. 3. Auto-namespacing is only to be used for internal reference to a global thing (eg. the re-frame database … (assoc db ::data-belonging-to-this-ns ,,,) … ugly, but it helps to track down its provenance in tools like re-frame-10x 4. No auto-namespacing ever for anything intended to be shared. It breaks grep and :: looks too much like : when I’m tired. I know things like clojure-lsp and cursive can overcome this but I like to keep lowest-common-denominator outside-the-editor tools like grep working OK.


(I also would put in a big upvote for related guidance on the idea that code namespaces and keyword namespaces don’t necessarily need to be conflated … when should they be kept in sync and when is it wiser to let them drift. IMO the conflation of the two leads to some pretty ugly and un-readable namespaced keywords. Sometimes I find a domain concept namespace hierarchy on keywords helpful and this doesn’t necessarily match up cleanly to the location of code files in a directory tree).


Im really looking forward to, that will reduce the annoying part of big names, by making it easier to alias, specially for the pure domain cases

💯 12

Hi there. So I’m playing around with spec and plumatic’s schema at the moment and I’m not sure how to approach this. In Schema, you can have (s/set-fn-validation! true) run and any function schema I define thereafter will be checked automatically. I notice that in spec I can do (stest/instrument) but it only works if I call it after the spec has been defined. Is there a way I can turn instrumentation on first and define specs later? Alternatively, what is the most standard workflow to use spec when deving?


@rextruong one way is to hook this in your (dev) component / integrant-like system, so when you restart it, the specs are instrumented


So every time I define a new function spec I’ll need to restart my dev component you mean?


similar to routes and a web server I guess


Ah I see. That’s indeed one way to do it.


Actually I may adopt that. Thanks 🙂


Hi there is overloaded java method

serviceConfiguration(Consumer<S3Configuration.Builder> serviceConfiguration) 
serviceConfiguration(S3Configuration serviceConfiguration) 
how I can type hint param so correct method is picked? I am trying this - but no luck
(.serviceConfiguration ^S3Configuration (-> (S3Configuration/builder)
                                                             (.pathStyleAccessEnabled true)
                                                             (.build))) please help thanks


The second overload of (.serviceConfiguration ...) that you need receives not one but two aguments - this and serviceConfiguration. You're providing only serviceConfiguration, thus replacing this with it.


my bad it is a bit trickier

(cond-> (S3Client/builder)

             (and access-key secret-key)
             (.credentialsProvider (StaticCredentialsProvider/create
                                    (AwsBasicCredentials/create access-key

             (-> (.serviceConfiguration ^S3Configuration (-> (S3Configuration/builder)
                                                             (.pathStyleAccessEnabled true)
                 (.endpointOverride (URI. endpoint)))



so this seems be provided


and the error i recieve indicates that it expects Consumer


Hmm, right. No idea why, sorry.


(fyi: there's always which I found really nice to use)


aws-api rather limited in its possibilities anyway, I’d like to understand how to type hint param so clojure can be proper method


maybe I'd remove -> and use simple chains (or let). -> can introduce some uncertainty if you aren't intimately familiar with it as a second trick, you can println the class of the object being built. maybe it's not what you think it is and as a last resource, you could use java's reflection api directly instead of clojure interop syntax