Clojurians Log v2

Good day! Does it makes sense if I use Clojure from Java? The reason is I am one of the team members in a project that uses Spring Boot and I am thinking of including the clojure jar as one of the maven dependencies. Then I will code some of the business logic in Clojure and call it from Java/Spring Boot while the other team members code in Java. I don't know yet how to call Clojure code from Java. Is it just using Reader, IFn, Clojure.var, etc? What are the recommended ways to mix the use of these 2 languages in a project if the team is composed of Java developers and Clojure developers?

@cjpangilinan it's quite easy https://clojure.org/reference/java_interop#_calling_clojure_from_java - clojure automatically initializes when you use it

As regards to how to organize things, I'd say it's similar to how any two subprograms are combined, though you should put more thought into it up front when crossing languages. Use require / IFn to get at and use clojure stuff from java, make sure the java side doesn't force you to do concrete inheritence or annotations which are clumsier on the clj side

@cjpangilinan You very much can, but if I had to guess it probably won't be the best way to introduce clojure to your team

Clojure really isn't "full duplex interoperability" like kotlin, and that tends to show

Is there a better way to write this?

I find myself often in this situation where based on the result of an if I should either return X or a modified version of X

for starters (if-not t ...) unless you expect false

how about #(cond-> % t (assoc :response {:status ... :headers ...}))

Yeah, I tend to reach for cond-> straight away for conditional modification of something.

We have a condp-> macro at work that is a variant that threads through the predicate, so I'd probably write

(condp-> t
  some? (assoc :response ...))

I upgraded to OS X Catalina and in the same time upgraded my brew packages, when I invoke clj -A:nREPL -m nrepl.cmdline -i I get

WARNING: When invoking clojure.main, use -M

@mikko can’t find the change log, it’s a new release of the CLI tools: https://clojure.org/reference/deps_and_cli

Here’s the release notes: https://clojure.org/releases/tools#v1.10.1.697

Oh, so it's clj -M:nREPL -m nrepl.cmdline -i now!

Thanks! 🙂

Using that, the warning went away.

Hi guys, I'm trying to use a Clojure function that returns an Array of Strings in Java. In the clj file I have: :methods [#^{:static true} [myfunc [String] "[Ljava.lang.String;"]]) (defn -myfunc [arg] .... (into-array (map str (keys some-sequence)))) When I try to invoke it from inside a Java class I'm getting: [Ljava.lang.Object; cannot be cast to [Ljava.lang.String; Does anybody have an idea why?

You want (into-array String ...) to give you a string array instead of an object array.

Wow, thanks! It even says that in the documentation of into-array. Wouldn't have thought that there's any special coercion functionality in that function. Much obliged!

Hi guys, is there any open-source ERP/CRM solutions in clojure(or wrapper) ? Thanks

@noisesmith @seancorfield Thanks for the pointer. I was also thinking about cond-> but I guess I haven't understood how to use it properly yet since it didn't look like it'd fix my use case

Oh ok I think I understand now

How come (= 3) ;; => true but (=) throws. This bites when (apply = xs) and xs happens to be nil or empty?

should (=) return true or false?

Hi everyone, is there something like tree-seq which could keep the structure of the tree?

i'm at situation of: i have https://nlp.stanford.edu/nlp/javadoc/javanlp/edu/stanford/nlp/trees/LabeledScoredTreeNode.html and want to convert to into native clojure

@dpsutton I'd say (= (=) (= nil)) (if that hadn't thrown an exception 😉

Unlike + or *, = doesn't really have a natural identity value, mathematically speaking.

But how does then (= nil) make any sense?

yeah i agree that the single arity doesn't really make sense

Not saying (= nil) makes perfect sense, but it makes more sense than defining a return value for (=) , IMO

but i'm not sure i agree that boolean logic doesn't have identities. seems false is the additive identity and true is the multiplicative identity, just like 0 and 1 under + and *

I think identity elements for or and and make sense, but less so for =

x || false = x for all x and x && true = x for all x

Thats like saying (> (* 2 (/ 1 0)) (/ 1 0)) 🙂

There is no value you can add to a list of (= a b c <insert-something-here) that preserves the return value for all values of a, b, c

oh you're right andy. i'm conflating things

You can do that for or and and (modulo short-circuiting behavior)

good point. thanks

That last one was to @andy.fingerhut claiming that (= nil) makes more sense than (=) 🙂

I don't understand the logic of your statement.

To me, saying that (= nil) makes more sense than (=) makes as much sense as saying that (* 2 (/ 1 0)) is greater than (/ 1 0)

I said "Not saying that (= nil) makes perfect sense". If you want me to back down from that, well, it isn't exactly a firm conviction in the first place, as I tried to convey (apparently unsuccessfully).

It was the , but ... that followed I was commenting on.

But I'm far away from being certain on anything in these matters. You actually wrote the guide on equality in Clojure.

I think it makes 0 sense to define a return value for (=) . I think it makes 1% sense to define a value for (= x) as true.

While I agree with this, the multi-arity = returns true when: ∀x∈S, ∀y∈S : x = y or ∀x∈S, ∄y∈S : ¬(x = y) When S is ∅ then both the above statements hold. So I think it’s valid to return true when applying = to the empty set

I can't exactly get worked up about the 1-arity = case in any particular direction, and it is less than 1% likely to change in Clojure.

I guess what I get worked up about is that this leads to unexpected runtime errors.

Much like the two-arity reduce can do.

Lots of things in Clojure lead to unexpected run time errors, if your expectations do not match the Clojure implementation. This is a fact of life 🙂

I am not thereby arguing that no one should ever ask about these things, or attempt to see if they ought to be changed. I've filed more issues than most people about nits like this.

This is also true, but this specific class of errors, applying a function which doesn't have a zero-arity variant to a list that sometimes empty, is not a class of errors I'm often considering.

@quoll That is almost true. Technically, it is when adjacent pairs all return true for =. There is no checking of all pairs performed.

I guess what I'm saying is that I'm totally fine with (apply < [1 2 \a]) throwing, but I'll always be surprised when (apply < xs) throws because xs is nil

You can write your own less-than function that doesn't surprise you.

I could write my own language that doesn't surprise me 🙂

(defn apply= [s] (or (empty? s) (apply = s)))

Sure can. Everywhere is walking distance if you have the time 🙂

> That is almost true.  Technically, it is when adjacent pairs all return true for `=`.  There is no checking of all pairs performed. I believe that is an implementation artifact, and not part of the definition

The definition you gave is a perfectly logical mathematical definition. It isn't part of the implementation, although the implementation is certainly guided by such ideas at some point.

I have lecture notes from 1989 that show a proof for: > if l=m and m=n then l=n We spent an hour on it, proving it via 2 methods. I only remember the second one. This was the class that convinced me that I was not interested in pure mathematics

If someone finds a case where = is not transitive, though, and (= a b c) returns true but (= c a b) returns false because of the implementation, and you point out that definition, what do you expect will happen? My expectation is "fix the non-transitive = implementation, if you can. If you can't, sorry"

My perspective here is that = is implemented in a way so as to express the mathematical concept as closely as possible. The implementation does not cover the case of (=) and the question raised was, “What does a zero-arity = even mean?”

Yep, and we talked about 4 mathematical functions that have very natural choices for identity elements, but = isn't one of them.

I proposed an answer to that. It doesn’t actually matter for the implementation, since the implementation is not going to change. But it should guide anyone who is wanting to apply = to an empty sequence

It looks like a fine definition to justify someone's choice of what their (my-custom-equals) function returns.

That argument would certainly persuade me that (=) should be true if anyone ever implements it...

Note that a change to (=) behavior could be considered by some as a breaking change, i.e. they expect it to throw an exception, because it has before. I have no knowledge of whether the Clojure core developers consider that a concern or not, for such changes, but it might be. Sometimes backwards compatibility means things that were error before remain an error in the future.

This description of Hyrum's Law is a good short read, if you haven't seen it before: https://www.hyrumslaw.com/

Yeah, I have had cases in projects where I've fixed a bug and then had users complain that they depended on the previous (buggy) behavior... and I've usually introduced some sort of flag that allows folks to choose which behavior they get (HoneySQL has several such flags at this point!).

I think in this case that it’s not about (=), since no one would call that. But rather what happens when = is applied to a seq and the seq happens to be empty. Which means that it just needs a function for applying = to a seq, and not changing =. Since it’s a boolean result, the function would be either: (defn apply= [s] (or (empty? s) (apply = s))) or (defn apply= [s] (and (seq s) (apply = s))) (I argue that it should be the former, as already stated).

Even if no one would call (=) in that form in their code, it seems like slipset is exactly concerned with the case of calling (apply = xs) where xs is an empty sequence or collection, and doesn't want an exception in that case. He knows he can write his own custom function for this. If he was content with that solution, I don't think we would have had a discussion with so many comments.

I was focused on the question asked at the top of this thread

This is correct. I’m first and foremost concerned with the apply thing. What the semantics of (=) is, is a side effect of the first concern.

There are several functions in Clojure that accept one or more arguments but not zero arguments and apply is painful for all of those (of course, now I can't actually remember what other functions I've seen people complaining about). I think we also have the situation that some n-arity functions have different semantics for their 0-arity form, returning a transducer? (again, can't think of an example right now)

I’ve used depstar to make a JAR of my library. Verbose output explains that it’s been compiled by JDK 14: Build-Jdk: 14.0.1 . I am worried if people with JDK 8 will be able to use my library.

The transducer ones I don’t mind, but <,>,=,not= all come to mind as the ones I mind.

Ah I see that JAR contains only .clj files, but what if any part of it was AOTed? How to select the java version level for those class files?

I would recommend using source and target of 8

Clojure itself is AOT compiled with Java 8

Most likely mixing the two is fine (but will require at least Java 14 to run an application, which may not be what you want).

Library JARs should not be AOT compiled in general. Uberjars can be AOT'd but the expectation is that you would run them yourself and you control the JVM environment on which they run @roklenarcic

one example: I publish an (uber)jar for the VSCode clj-kondo extension which only requires people to have Java (8>=) on their system

I make sure I compile with 8 (by printing the java version before compilation, there are better ways)

I use jenv to quickly switch between java versions per project or shell

I guess I could not AOT this and rely on clojure main to invoke this right?

if clojure was part of the uberjar

java -jar clojure.main -m ...

surely java -cp some.jar clojure.main -m ...

Is there something like JS' "Shorthand property names" in clojure.core? I'd imagine there is some macro that creates {:a 1 :b 2 :c 3} from (let [a 1, b 2, c 3] (shorthand [a b c]))

(defmacro as-map [& syms]
  (zipmap (map keyword syms) syms))

related

(ins)user=> (defmacro locals [] (into {} (map (juxt keyword identity)) (keys &env)))
#'user/locals
(ins)user=> ((fn [x] (let [y (+ x x)] (locals))) 21)
{:x 21, :y 42}

@victorbjelkholm429 I have this one in a project I work on:

(defmacro ->map
    "(->map a b) ;;=> {:a a :b b}"
    [& symbols]
    (assert (every? symbol? symbols))
    `(hash-map
      ~@(interleave (map keyword symbols) symbols)))

hello! is there a good way to check whether a function (passed as an argument) has 0 or 1 arity? (I am trying to find a non-breaking way to evolve an API that previously took a 0-arg callback while I want to start sending it an argument, w/o breaking all existing clients)

hello, is there a way to leverage the structural sharing for transfering data? my use case is that I have a map that goes though a complex series of operations until its done, to help with debug I'm doing snapshots of this map as the program builds it up. while running on the machine I get the memory savings from structural sharing for free, but I also need to transfer that data (all the snapshots) over the wire, and if I do that, than there is no structural sharing to help reduce the data size. so I wonder if there is a solution around for that

AFAIK the function object itself doesn't expose that information

@holyjak Only in the unsupported realm of hacks: https://stackoverflow.com/questions/1696693/clojure-how-to-find-out-the-arity-of-function-at-runtime

@wilkerlucio transit does some structural sharing, there might be something else that does it more aggressively

What I mostly end up doing when designing an API is MIMO: map in, map out. This has enough flexibility for future extension

you could also just catch an ArityException and handle the old case in the catch

thinking out loud - you could also use dynamic bindings instead of providing the values as args (the way clojure.test encourages for example)

but using a hash map in the first place definitely wins

metadata opts on the fn also works

bit of a hack maybe, but it works

Thank you all! What do you mean by metadata opts, @borkdude ? The metadata added automatically by clojure for regular functions? That could be a good optimization to try but they will be missing for anonymous fns / lambdas so I would still need to catch the ArityExc. @noisesmith Yeah, I thought about dynamic bindings but it feels very non-functional and opaque, passing data like that, I prefer an explicit solution.

@holyjak Never mind, the metadata solution won't work. I think the ArityException solution might be the least hacky if you want to keep supporting the 0-arity

I'd say (try (f x) (catch ArityException _ (f))) is the simplest (and performs better than the reflection option)

yep

I hate to suggest it but java serialization is probably the best example of that

Objects in the stream are only transferred once

I don’t recall if Clojure collections are customized though in such a way that would foil structural sharing, can’t look atm

@wilkerlucio @alexmiller a simple proof of concept, the baseline usage for clojure data structures is a bit large

(defn to-bytes
  [& data]
  (with-open [b (ByteArrayOutputStream.)
              stream (ObjectOutputStream. b)]
    (doseq [d data]
      (.writeObject stream d))
    (.toByteArray b)))

(defn from-bytes
  [ba]
  (with-open [bs (ByteArrayInputStream. ba)
              stream (ObjectInputStream. bs)]
    (into []
          (take-while (complement #{::done}))
          (repeatedly
           #(try
             (.readObject stream)
             (catch IOException _ ::done))))))

(ins)user=> (to-bytes {:a 0 :b 1})
#object["[B" 0x4784013e "[B@4784013e"]
(ins)user=> (def b *1)
#'user/b
(ins)user=> (count b)
536
(ins)user=> (from-bytes b)
[{:a 0, :b 1}]

is there any way to show that this method takes advantage of structural sharing of clojure's data structures?

working on that now - making a relatively large structure and putting it in multiple spots in a parent coll

I've long been interested in the idea of being able to have a poor man's database just by doing (write-to-disk-on-change my-atm) and it would simply write the atom to a file and as long as you're just conjing onto some clojure data, it might theoretically be able to sync with the on-disk file incrementally. still not sure it's a good idea

this is what databases are for right?

yea, but it may be ignorance of the options, but if I have some nested maps, is there a database that can sync incrementally the whole nested data structure?

for example, a map that holds all the UI data for a re-frame app

When it comes to the ‘heavies’ in the Clojure community (years in the field, active in core development, etc), what’s the approximate distribution of CIDER, Cursive, etc? Any idea?

there's a yearly survey that asks about tooling / editors etc. but I don't think it's broken down to cross reference experience and tooling together

thank you!

I can't remember if the survey writeup also makes the raw data accessible, but that would be the way to figure it out I guess.

My impression is that it’s probably roughly 50/50 Cursive/Emacs. But on the Emacs side my impression is also that a lot of the more experienced people tend to use simpler Emacs setups, i.e. probably clojure-mode but not CIDER. I have no data to back that up though.

I get the impression that the "heavies" use the tooling in roughly the same percentages as the overall community, with a slightly heavier lean toward Emacs. Yeah, what Colin said...

Rich and Stu (and several other "long-timers") use Emacs in a fairly minimal configuration: inferior-mode, plain REPL, perhaps via a Socket REPL in some cases?

If I ever went back to Emacs, I'd probably go down that path instead of CIDER. Ideally, I'd want a way to connect Emacs to a Socket REPL. I'm probably a bit of an outlier as I used Emacs on and off since way back in its 17.x version days, and came back to it once I got into Clojure a decade ago after trying a few other editors. But then I switched from Emacs to Atom back in 2016 I think? And I use Atom/Chlorine, a Socket REPL, and a deliberately minimal set of key bindings and commands now. I was using Cognitect's REBL but I've switched to Reveal now for the most part (because it's easier to customize and it's getting new features faster).

We run Socket REPLs in a lot of our processes, so having an editor that can connect to a Socket REPL and eval code from source files that way is very important to my workflow -- in fact I just patched a bug in production that way about 30 minutes ago 🙂

https://clojure.org/news/2020/02/20/state-of-clojure-2020 - emacs at 43%, then intellij, then vscode, then vim

everything else is under 10%

range and repeat may be too specialized to really test this theory