@borkdude thought you'd appreciate this quote from a classic paper on incremental parsing

So Malli showed a pretty nifty sneak peek of clj-kondo integration, where you could define the inputs and outputs of a defn and kondo could somehow lint their usage. Is that something that kondo can do today? And if yes, do the types “flow” down to functions calls etc?

@orestis They are using the format described here: https://github.com/borkdude/clj-kondo/blob/master/doc/types.md

yes, the types "flow" in let and function return types

My use case is, I have some functions whose arguments can be described pretty tightly (they are GraphQL objects). I’d like to be able to catch mistypes, checking for keys that aren’t there (closed types) etc. Doing it at the syntax level like demonstrated would be cool, but I could also do it on my own.

Some example:

(defn my-resolver [context args _]
  (let [subtype (:foo args)]
    (deal-with-subtype context subtype (:bar args))))

@orestis there is this now: {:op :keys, :req {:a :string} :opt {:b :int}}, but that's mostly for checking map literals at callsites

not sure how well that works with "flow", I expect it not to work at all at the moment.

Can I somehow “lint” that :foo is actually part of some spec? Can I somehow lint that the third argument deal-with-subtype ( (:bar args) ) is a sub-spec of the bigger spec?

Sorry if this sounds too vague, I don’t have the terminology figured out…

I have currently one function in clj-kondo that is typed using the :keys: https://github.com/borkdude/clj-kondo/blob/master/src/clj_kondo/impl/findings.types.edn No, there is no spec-like thing

Where spec could be malli -> which is what piqued my interest

I don’t necessarily want to have clj-kondo itself do this, but it seems like it may be generating information I could then piece together on my own? Or would I go to tools.analyzer for this?

@orestis clj-kondo doesn't generate any type information

afk now, ttyl

Np, I’ll see if I can explain myself better in some clojureverse post 🙂 Thanks