Oh Yeah!

How does it interface with custom registries and custom schemas?

Cool! What is the tooling like nowadays? Does it require REPL (so it is one the same classpath as the running app) or could it be integrated into clojure-lsp?

@UK0810AQ2 it's a https://github.com/typedclojure/typedclojure/blob/4818f27a4661262b0d8268a6b00bd0363b02dba0/typed/malli/src/typed/malli/parse_type.clj#L196 right now for custom schemas, a big case. Could probably be a multimethod, do you have an example of a custom schema to help me understand the design space? And custom registries, I'm not sure how far it gets me, but I use m/-deref when I find a :ref. That should be enough?

@U061V0GG2 requires a REPL since it macroexpands code.

Maybe if we create a custom macro rule for every macro in clojure.core we can think of a clojure-lsp version.

A good example of custom schemas would be for time types, such as https://github.com/metosin/malli/pull/545 Similarly for other iterop-y parse-y things, like valid URIs

ok, I think we need something like (defmethod malli->Type :local-date [_] 'java.time.LocalTime) .

Maybe if the :class were propagated to the schema itself it would be even simpler.

So if those schemas had a way to query their backing class it would make it easier to participate in typed.clojure?

in the simplest cases, yes. Is a "simple schema" usually tied to a class?

No, but I could petition for something like "simple class schema" which could back various boring data classes

And maybe add in malli a protocol for accessing those

that sounds perfect.

Can you think of any custom registry case that might be problematic? I just call m/deref to convert the entire schema eagerly.

Recursive schemas?

ah yep, I handle those https://github.com/typedclojure/typedclojure/blob/4818f27a4661262b0d8268a6b00bd0363b02dba0/typed/malli/src/typed/malli/parse_type.clj#L236

Should be fine How about dependent schemas?

Example?

https://github.com/metosin/malli#content-dependent-simple-schema

probably would need a custom m/type dispatch in the (future) malli->Type multimethod.

another way these simple schemas could be automated is if Typed Clojure could know the var backing the :pred. eg., pos-int? here

because the checker has the annotations for these preds

but there's a lot of info in the json-schema props too.

perhaps a :type-properties :typedclojure/type convention might be useful too.

this is great 🙂

thanks Tommi 🙂

the actual printer is silly here, should separate the input & output schema problems, looking forward to seeing what you @meditans cooked up for this.

but, the core-lib support pretty-anything now. the helper looks like:

(defn prettifier [type title f options]
  (let [printer (assoc (or (::printer options) (assoc (-printer) :width 60)) :title title)
        actor (::actor options reporter)]
    (fn [& args] (when-let [res (apply f args)] ((actor printer) type res) res))))

I am in fact still at a prototype stage re: precise messages (and I mainly produce hiccup to pass to #portal, which I'm trying to turn in my repl for visualization). But I'll definitely try this out and upstream improvements if I end up making them for myself. I have to say, ideally for me, this prettified error message would be more usable in the form of a data structure (from which I can generate hiccup). But I can as well keep producing it myself from the error!

I think a shared function of check-explanation to some intermediate map would be good and could be used by both the malli pretty-printer and your portal visualizer.