How much work is involved to make a Clojure dialect which runs on a non-java runtime (like Clojurescript does)?

is it just map a few dozen primitive operations to the new runtime and fill in the blanks for parts of the standard library that are runtime dependent, or is it much more involved then that?

looking at the clojurescript compiler, it seems to be a completely different entity to the clojure compiler, so I guess it's probably fairly involved

it’s a lot of work - check out all the java under the hood

@ludvikgalois What do you want to do?

Nothing serious, I was just hoping to get a (reasonable) subset of clojure running on GNU Guile for a joke. But it looks to be a fairly large amount of work.

For the purposes of the joke, it's much easier to just write "Scheme" with syntax that looks like Clojure and then compile that to Scheme. That only involves needing to write something to parse EDN

I wouldn't call it Clojure without immutable maps, vectors, and sets, and those are all implemented in Java for Clojure. They are implemented in ClojureScript, but that would require implementing deftype and protocols on a new target, at least.

maps, vectors and sets are all HAMTs under the hood, aren't they?

not vectors, but sets are implemented using the map implementations.

I'm not saying any of that is an insurmountable hurdle, by any means, especially given the existing implementations to go from. Just mentioning some things you definitely want to be sure to implement on a new target.

Your irregular reminder - the Exercism Clojure mentoring team is still looking for more mentors. Join us and use few 10s of minutes / month to help a beginner learn Clojure! https://exercism.io/become-a-mentor 🙏

Hey folks, how can I define limited thread pool in clojure?

@quieterkali https://github.com/TheClimateCorporation/claypoole

I have a jar file. How can I include that in leiningen as a dependency?

that jar file is not available on maven

Hey, let’s say I have something like a.clj

(ns a
  (:require [c]))

(defn eval-f
  [f]
  (eval f))

(ns b
  (:require [a]))

(a/eval-f '(c/some-fn))

(defn eval-in-ns
  [ns form]
  (binding [*ns* (find-ns ns)]
    (eval form)))

Are there any proper document or source about Strings on Clojure. They are implements serializeable interface but how, why ?

Clojure strings are host strings. Nothing special about them.

I’ll write something about why this call works like smoothly, (map identity "bello!").

But I must be sure about my understanding over it.

Yeah, I know that.

Because Clojure Strings implements Serializeable interface.
*A lot of* false-sources are saying Clojure Strings *are* Sequences, but it is all about interface implementation.
Clojure Strings are just Java Strings.

You think that strings can have seq called on them because they implement the serialize interface?

strings are java.lang.Strings

the Clojure runtime has special case code to treat Strings as "seqable"

when you call seq on a string, you get a sequence of characters

Yeah, I know that. But I have to need a proper explanation about it.

that's the whole story

serializable has nothing to do with it

I don't know of any reference documentation about it

This will suffice for the explanation, thank you guys. But I’m very curious person. I need to dig about it.

seq function has some documentation on it. Not about implementation, just about the contract.

There's a few special cases: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L541-L559

Ok, this special treatment comes from Clojure Run-Time. But, are there any special situations like this ?

What do you mean? (seq "").

Or do you mean any other special cases?

Anything else.

Just search for instanceof in the RT.java file. :)

I’m doing it. 🙂

BTW, is RT.java considered implementation detail? I.e. does it need to preserve backwards compatibility in terms of its interfaces?

Nice question.

Anyone ?

I think the general answer is if it's not in the documentation under "reference" or API on http://clojure.org then it may change

I started to wonder because I saw clojure.lang.RT#assocN with a comment that says: "//hmm... this is not persistent". But at the same time, this static method is not used anywhere (well, except if there's some obscure reflection going on).

"is RT.java considered implementation detail?" yes "does it need to preserve backwards compatibility in terms of its interfaces" yes

AOT compiled Clojure includes calls into RT and thus we try pretty hard not to break binary compatibility with the RT interface (or Clojure code compiled on an old version would not run on a new version). I actually can't think of a bug report or complaint like this in my memory so I think we do a pretty good job at that.

you may find some vestigial methods in RT that are no longer used but have been preserved for compatibility

Oh, so ABI is still relevant here. After halting any serious work done in C++ I kinda stopped having this problem and eventually forgot about it completely. I see, thanks.

most Clojure code is distributed and consumed as source (so late-compiled when used) so it's usually not something to worry about much

Clojure core is a bit special in being a mix of Clojure and Java and mostly AOT compiled

Is it possible to get meta information about a function at run time? I captured the var in a atom, derefing it tells me the fn sig (in emacs with cider). But i'm curious if you can get more information at run time. I would link so, but my first pass (meta @foo) didnt work.

from a var or a function instance?

for the former, meta should tell you things. for the latter, no it's opaque (just an invokable thing)

"capture the var" is unclear to me which one you did

(meta @foo) is pulling the metadata from the fn

(meta #'foo) pulls the metadata from the var

Just talking about terminology. What would describe this:

(defn foo []) 
(def d (atom nil)
(defn zoo [x] (reset! d x))
(zoo foo)

for the record this is what ended up working to publish 2 jars with different deps from a single project

:aliases {"deploy!" ["with-profile" "default:fixture" "deploy"]}
  :profiles {:test-deps {:dependencies [[org.testcontainers/testcontainers "1.12.3"]
                                        [org.testcontainers/postgresql "1.12.3"]]}
             ;when we run `lein with-profile fixture install` (or `lein deploy!`), gr-db/gr-db-fixture-{version}.jar is published with the test-deps included in the pom.xml
             :fixture ^:leaky [:test-deps {:source-paths ^:replace ["src-helper"]
                                           :name         "gr-db-fixture"}]
             :dev [:test-deps {:resource-paths ["test-resources"]
                               :source-paths   ["src-helper"]
                               :dependencies   [[ch.qos.logback/logback-classic "1.2.3"]]}]}