Any reason why?

Ya, I was just lazy in my example, my use case returns a custom Java object

or coll literals, I make that mistake from time to time :)

I'm not sure where you are in your Clojure journey but that sounds like a question perhaps better suited to #beginners where folks have opted in to help folks learn Clojure in depth.

This channel tends to assume a level of experience that is likely to get you short and sometimes sharp answers that may not provide enough detail.

From your question, it sounds like you are considering using def inside another function @UH13Y2FSA?

def is always global so you should pretty much never use it inside a function. If you're thinking about side effecting code, you'll probably want to explain more of what you're trying to do -- a lot of beginners reach for atom when they would use a regular (mutable) variable in another language.

yes, i'm wanting to keep a lookup dictionary, that can be added to, but i don't expect client code to hold it for me. client code should be able to resolve using the dict using functions in that same namespace, but also be able to add to it as well... multiple threaded

i'm sort of presuming atom is needed since it's multiple threads, but wasn't sure if that was overkill

Use an atom. Definitely not overkill.

https://clojure.wladyka.eu/posts/share-state/ I hope you will my article helpful. Give me some feedback if you like to :)

PS disclaimer: the article was targeted to developers who have experience with Clojure. I don’t know if it is easy to understand for developers who start Clojure journey.

having had a previous "lisp-life" in general I feel comfortable with clojure, but the things that are specific to clojure outside of the "new" data structures not so much. So yes, this article hits that gap in knowledge, thanks.

As far as I know instants are the best to use. But I don’t use datomic, so I don’t know if this can have effect on this choice.

What you mean by “instants in some specified timezone”? Instants by definition don’t have timezone information ir rather they assume UTC

I worded it clumsily. I meant saving instants and converting them to the users local timezone on the “last mile” before showing them.

Call extend again

From the previous example:

(require '[clojure.core.protocols :as p])
(require '[malli.core :as m])

(extend-protocol p/Datafiable
  Object
  (datafy [x]
    (cond
      (satisfies? m/Schema x)
      (do
        (extend-protocol p/Datafiable
          (class x)
          (datafy [y] (m/-form y)))
        (p/datafy x))

      (satisfies? m/IntoSchema x)
      (do
        (extend-protocol p/Datafiable
          (class x)
          (datafy [y] (m/-form (m/schema y))))
        (p/datafy x))

      :else x)))

The thing is that I'm not sure extending-protocol for object is a good idea. If there is going to be another similar piece of code using the same trick, you I might get an undeterministic behaviour (well, deterministic but depending on the order of form evaluation). Have a look at the below example:

(require '[clojure.core.protocols :as p]
         '[clojure.datafy :refer [datafy]])

(defprotocol ProtA (say-a [_]))
(defprotocol ProtB (say-b [_]))
(def sample-prot-a (reify ProtA (say-a [_] "a")))
(def sample-prot-b (reify ProtB (say-b [_] "b")))

(say-a sample-prot-a) ;=> "a"
(say-b sample-prot-b) ;=> "b"
(satisfies? ProtA sample-prot-a) ;=> true
(satisfies? ProtB sample-prot-b) ;=> true

(extend-protocol p/Datafiable
  Object
  (datafy [x]
    (if (satisfies? ProtA x)
      :a-object
      x)))

(datafy sample-prot-a) ;=> :a-object

(extend-protocol p/Datafiable
  Object
  (datafy [x]
    (if (satisfies? ProtB x)
      :b-object
      x)))

(datafy sample-prot-b) ;=> :b-object
(datafy sample-prot-a) ;=> #object[dev$reify__57541 0x3a89db1d "dev$reify__57541@3a89db1d"]

It's not perfect but calling satisfies every time is bad

Well, I think your example is better, not only because the satisfies. In your example, you extend on the specific type of malli class, so even if the someone calls again (extend-protocol p/Datafiable Object ...) it is ok, as long as the datafy was called on every Malli type.

Some alternative could be extending each Malli type separately, like:

(let [forms [[:and any?]
             [:map]
             [:map-of string? string?]
             [:multi {:dispatch :t}]
             [:or any?]
             [:orn [:a any?]]
             [:sequential string?]
             [:vector string?]]]
  (doseq [f forms]
    (extend-type (class f)
      p/Datafiable
      (datafy [x] (m/form x)))))

There are lots of types there, and you also miss out on user extension

I borrowed this implementation pattern from Clojure Applied

Page 23, Extending Protocols To Protocols

Haha, I read this book in the past. I've just grabbed it to check that page and what is there? An explanation mark to remember this trick 😄

😄

looks like in compile-directive it's calling (Character/toUpperCase ^Character directive) where directive is (first rest) which is assuming that the next character (after the @) is not nil ... right? ... that's the cause of the null pointer ... I'm pretty rusty with by cl-format, is that just a bad error message?

a trailing ~@ seems to violate the description of what it should do, right? cos the newline is missing??

yes I think you're right. it shouldn't have a null exception, but rather complain that it is expecting at least one character after the @ ???

putting a newline after the @ works.

(cl-format false "~&~
                            item=~A~@
                            transitions=~A~@
                            lhs=~A~@
                            rhs=~A~@
"
                      1
                      2
                      3
                      4
                      )

in common lisp

(format nil "~@")

error in FORMAT: String ended before directive was found
  ~@
  ^
   [Condition of type SB-FORMAT:FORMAT-ERROR]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT] abort thread (#<THREAD "repl-thread" RUNNING {1004289BC3}>)

Backtrace:
  0: (SB-FORMAT::FORMAT-ERROR-AT* "~@" 0 "String ended before directive was found" NIL)
  1: (SB-FORMAT::FORMAT-ERROR-AT "~@" 0 "String ended before directive was found")
  2: ((FLET SB-FORMAT::GET-CHAR :IN SB-FORMAT::PARSE-DIRECTIVE))
  3: (SB-FORMAT::PARSE-DIRECTIVE "~@" 0 NIL)
  4: (SB-FORMAT::%TOKENIZE-CONTROL-STRING "~@" 0 2 NIL)
  5: (SB-FORMAT::TOKENIZE-CONTROL-STRING "~@")
  6: (SB-FORMAT::%FORMAT #<SB-IMPL::CHARACTER-STRING-OSTREAM {10045EAB73}> "~@" NIL NIL)
  7: (FORMAT NIL "~@")
  8: (FORMAT NIL "~@") [more]
  9: (SB-INT:SIMPLE-EVAL-IN-LEXENV (FORMAT NIL "~@") #<NULL-LEXENV>)
 10: (EVAL (FORMAT NIL "~@"))

ahhh I see what's happening. the @ is just a flag to the "~ " directive. that's clever. I never realized that before. I thought ~@ was the directive. duhhh

I doubt it is the most obscure sentence in the specification.

Don’t know if you found my explorations helpful or not with respect to providing more information on the issue with cl-format regarding it yielding a informative error message rather than a NPE…

it says this at the top of the file:

;; Author: Tom Faulhaber
;; April 3, 2009

user=> (hash {:a :b :c :d})
1986597936

ah-ha, thanks!

and a good way to find that is (apropos "hash")

Ah I didn't know that either, thanks a lot

Might need to type (clojure.repl/apropos "hash") , depends on the type of REPL, I guess

clojure always runs (apply require clojure.main/repl-requires) which ends up referring clojure.repl/apropos to your startup ns, but some repls end up changing ns after startup

luckily that one liner isn't super hard to run in whatever ns you end up in

for reference

user=> (pprint clojure.main/repl-requires)
[[clojure.repl :refer (source apropos dir pst doc find-doc)]
 [clojure.java.javadoc :refer (javadoc)]
 [clojure.pprint :refer (pp pprint)]]
nil

question was do other people find this cryptic or is it a perfectly valid clojurism? BTW good to know about the .invoke function. thanks.

Strictly speaking it is a method)

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java can be considered a public API. It even shows up here: https://clojure.github.io/clojure/javadoc/clojure/lang/IFn.html

its about 50/50. the propietary lisp1 that I used for many years had a funcall function which people used for this case, but was normally redundant.

yes if you want to do it with a macro, I guess you really need to preserve the meta data. wouldn't it be better with a normal lambda function? Something like the following untested:

(defn funcall [f &rest args]
   (cond (empty? args)
         (f)
         
         (empty? (rest args))
         (apply f args)
         
         :else ;; need to assert (last args) is a seq!
         (apply f (concat (butlast args) (last args)))))

Besides the very heavy performance overhead of calling last/butlast and apply/concat, the macro is repeatedly left associative, which means you can write stuff like (>- f x y z) which will expand to (((f x) y) z) , could be useful if you're doing stuff based on untyped LC

(require 'clojure.pprint)
(in-ns 'clojure.pprint)
(defn compile-directive ...)
(in-ns 'your.ns)

does the trick. Thanks for the suggestion.

I updated https://ask.clojure.org/index.php/10897/is-this-a-bug-in-cl-format?show=10900#c10900

Not sure why the restriction to not be able to create defs outside the current ns is a necessary restriction. 😡

I would say because it destroys locality of definition. If "any" code goes around redefining things in other namespaces then a) you can no longer rely on just looking in the namespace where its source lives and b) the semantics of the function now depend on the order that code is executed. Both of those are a Bad Thing(tm) in maintainable code.

That's an interesting idea, but it doesn't work. I can still call in-ns in any file, and end up doing the same thing in a less declarative way. It seems to me that allowing the more declarative defn x/foo or def x/foo would only help to find definitions rather than obscure them. Plus, one of the features of defmethod is that even if the defmulti foo is defined in namespace X, I can define methods on X/foo in many different files thus allowing applications to extend a multi-function.

Sure, but this makes you work at it and deliberately doesn't normalize it. That is usually Clojure's way.

> Is clojure.core AOT compiled? Yes.

> Would this be a good approach? I think so, just make sure "AOTer" and "production" environments match. Same JDKs, identical classpaths, etc Best achieved at CI level

Yeah, it might be actually a problem - I'll need to check. We have to support Java 8 in some environments but in others (like our Docker image) we can count on JDK 11.

Might be stating the obvious but that would be a good reason to generate different AOTed artifacts on a CI matrix

@U2FRKM4TW Where can I check that core is AOT compiled? I skimmed https://clojure.org/reference/compilation but didn't find it there - only that it's directly linked

> As of Clojure 1.8, the Clojure core library itself is compiled with direct linking.

If you open the jar, you'll see a load of .class files.

Ah right, so compiled is the same as AOT-compiled - yeah, i guess that's obvious, just being a bit confused.

Is it possible to make use of direct linking without AOT? - I'd think so but...

Yes

btw being pedantic "compiled" can also apply to any use of clojure.core/compile... which you can invoke at runtime, which makes it a case of non-AOT compilation

Yeah, but the net affect is the same/similar? That is a class file being written to the disk. Perhaps there's a difference depending on how/when you load the code that is being compiled - before vs after compilation?

Hmm, I was surprised that the above code works well in AOT-compiled uberjar: • when run with Java 8 it returns empty collection • when run with Java 16 it returns expected processes.

> Yeah, but the net affect is the same/similar? That is a class file being written to the disk. > Perhaps there's a difference depending on how/when you load the code that is being compiled - before vs after compilation? Subtle one, I think I'd need a refresher for accurately answering :) I think that clojure has a contractual priority when finding both a .class and .clj file (don't ask me which ;p) The classpath and order of operations might also affect

> Hmm, I was surprised that the above code works well in AOT-compiled uberjar: yeah tbh it looked like it would just work. It partly depends on the use case. If you want to rest assured that you won't find opaque issues in a future I'd go the "pedantic route" and create fine-grained artifacts as menioned

Anyway, thank you both for the advice!