This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
The https://www.unison-lang.org/ language reminded me of the old https://github.com/Datomic/codeq project. I am wondering if there is any interest in having clj-kondo work off a codeq style data store maybe backed by https://github.com/replikativ/datahike or https://github.com/threatgrid/asami.
The clj-kondo https://github.com/clj-kondo/clj-kondo/blob/master/analysis/README.md can be stored in such a data store. In fact clojure-lsp has been doing this in datalevin for a while, but now it's using transit (like clj-kondo itself). Once you know the queries you're going to do you can optimize for that in your storage format. Clj-kondo tries to conservative in the amount of dependencies involved, so it's not using datahike or asami, just transit files.
Thanks. I didn't know clojure-lsp was using datalevin. It seems like a global, immutable, semantic, content addressable code store would benefit every level of the tool chain. I am wondering what are the possible incremental steps to enable it in the various tools. I totally get keeping clj-kondo lightweight with minimal deps. Maybe there is a setup where a standalone code store is available, and tooling could optionally hook into it to gain additional super powers?
@U071T1PT6 I believe you are right about the content addressable code store. I think clojure-lsp and clj-kondo and others are “small” incremental steps towards this (in my opinion). Recently someone coined a related initiative with #C03FF6W62A3 Not sure where this is going, but you might find some more ideas there. I also thought of https://clojurians.slack.com/archives/C03FF6W62A3/p1653908127822239?thread_ts=1653905543.461139&cid=C03FF6W62A3
@U0FT7SRLP Definitely relevant. Thanks for the references.