It's probably overkill but apache lucene might help

Yeah.. I’d like to keep my dependencies lightweight if possible, but I guess Lucene might be a good fallback if I can’t figure out something better 🙂

Alright, turns out that implementing this thing on my own was actually pretty straightforward

I’ll have to tweak various weights for the result quality to match FZF, and I might have to do some optimizations to handle large sets of strings, but overall a quick implementation of Smith-Waterman (https://en.wikipedia.org/wiki/Smith%E2%80%93Waterman_algorithm) with a few adjustments seems to work well enough

what do you mean by "call sub project.clj's" - is the parent project somehow consuming / transforming the child project definitions? usually you'd create an artifact from each project, and the parent project would use the artifact produced by the child

Have you read SICP, by any chance? The older edition - the one that still used Scheme and not Python.

I re-checked the toc of sicp. It may seen a little bit abstract, and didn’t directly cover what I said. So to rephrase my question, is there a place to lookup idiomatic clojure code on, for example, topo sort ?

SICP will help build your intuition around imperative vs functional code, but it won’t help you look up specific algorithms. To answer your question, there’s no single resource that I know of for Clojure algorithm implementations — but maybe you should create one? 😉

As for BFS and topological sort, it may be helpful to note that BFS/DFS is just recursing over a graph with a stack/queue to hold the state.

BTW if there’s a way to state your algorithm recursively (as for BFS/DFS) then that’s generally going to be a lot simpler/more idiomatic to express in Clojure than an imperative equivalent

@UGC0NEP4Y i dont have a general answer but for an example of topo sort in clojure I found stuartsierras library dependency from which I "stole" some structures for a golang implementation lately: https://www.github.com/stuartsierra/dependency/tree/master/src%2Fcom%2Fstuartsierra%2Fdependency.cljc

Loom is a good library to refer for functional graph algorithms

There's an SICP that uses Python? TIL!

@UGC0NEP4Y the bargain one makes when using a language like clojure with immutable data structures is reduced flexibility (the implementation of graph algorithms or even tree algorithms is more convoluted) in exchange for a better set of guarantees about behavior (knowing that you don't have subtle bugs caused by out of order mutations, because you aren't mutating things). The normal trade off is to not use those mutable algorithms, instead using immutable data and a combination of the methods those data structures implement and set operations, lifting what would be mutations into new immutable recursive calls. This is less efficient but easier to do correctly. When one finds bottle necks, you can move over to the tricker but better performing mutable version.

I mean, if you want it you can literally do contiguous bytes with pointer operations on the JVM, it performs very well. We avoid it because it is very easy to do wrong.

yup. there should be some dedicated data structures, adt, for those tree/graph operations. While in a mutable world, we just use a queue, a visited set, or vector 2d board (adjacet list/matrix) for those stuffs.

sure, and we have queues (clojure.lang.PersistentQueue/EMPTY) sets, and two dimensional vectors

it's not hard to make an adjacency list, but yeah, those are great for graphs and it's too bad we don't have a standardized one in the language

maybe there's a lib with enough traction to standardize on though

and for more perspective, if it isn't clear, our set / hash-map / vector all use a variant of a balanced tree under the hood https://worace.works/2016/05/24/hash-array-mapped-tries/

user=> (ns bob (:refer-clojure :exclude [def]))
nil
bob=> (def x 1)
#'bob/x
bob=> x
1
bob=> (defn def [x] :new-thing)
#'bob/def
bob=> (def 3)
Syntax error compiling def at (REPL:1:1).
First argument to def must be a Symbol
bob=> (in-ns 'user)
#object[clojure.lang.Namespace 0x301d8120 "user"]
user=> (bob/def 3)
:new-thing
user=>

def is a special form. when when calling def it is always the clojure.core/def special form. however, you can define a def function, and when called with an alias or fully qualified form, its can be resolved

and the exclude there is to prevent a warning that you're defining a def when clojure.core/def already exists

you can't "not use" a special form because the compiler always handles that for you.

Thanks! I forgot about the special form.

user=> (let [def :foo] (def {:foo :bar}))
Syntax error compiling def at (REPL:1:17).
First argument to def must be a Symbol
user=>

kinda the same thing here. you can create a binding for it but you can't "access" the binding. because the compiler treats def as the special form and doesn't care if there's a local

Whowww

Makes sense once I think about it, but I did not see that one coming.

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L7106

i think its here. its analyzing a seq. if its a special, it analyzes it as a special and the else after that is "look up the function in the first position and go with that"

Clojure/script is my first/primary language. Its always baffeling when that java-stuff shows up :-DDD

That always feels like living in a shiny spaceship and lifting a sidepanel and its all Kables beneath ;-)

Thanks again!

in cljs its a bit more straightforward

(defn analyze-seq* [op env form name opts]
  (if (contains? specials op)
    (parse op env form name opts)
    (parse-invoke env form)))

and

(defmethod parse 'def
  [op env form _ _]
  (when (> (count form) 4)
    (throw (error env "Too many arguments to def")))
...

parse is a defmulti that knows how to parse the special forms

Nice idea to check it in cljs.

cljs is often easier to follow the logic for this kind of stuff

its clojure in clojure rather than clojure in java

compiler.java vs analyzer.cljs

thank you again!

of course