I'm pretty new to clj/s and even more so core.typed - but the new support for 'providers' and the support for malli made me wonder: This is prob dumb, but does core.typed play at all with spec (v1)? I ask bc I wonder if something like plumatic.schema (or some special subset or wrapper etc thereof) could be used to define the kind of static typing that core.typed provides but also runtime validation? I'm not sure that I would use the same schema or definition at both "-times", but the syntax in any case is very slick, reminds me of ts a lil. In any case, I appreciate the hell out of your work on this @ambrosebs ❤️

@rayatrahman9 great questions, and I appreciate your shout out. I've done a lot of experimentation in this area. > does core.typed play at all with spec (v1)? Not in the same way (yet). I've https://github.com/typedclojure/typedclojure/tree/main/typed/clj.spec making spec2 specs more expressive so type-like specs can be written, but I never hooked this up as a "type provider" (I also have a private branch that adds spec1 support in the same way).

> I ask bc I wonder if something like plumatic.schema (or some special subset or wrapper etc thereof) could be used to define the kind of static typing that core.typed provides but also runtime validation? I agree that integration with a 3rd party lib is the way to go for runtime validation. Schema and malli are great candidates. spec2 is very cool and flexible, spec1 needs more thought to integrate with the type system.

> I'm not sure that I would use the same schema or definition at both "-times", but the syntax in any case is very slick, reminds me of ts a lil. Yes. https://github.com/arohner/spectrum has a neat idea: use spec1 syntax and add "static type" overrides on the level of spec1 registry entries.

> syntax in any case is very slick, reminds me of ts a lil. My current hunch is that people will be drawn if they can use their chosen runtime validation library's syntax, and then only occasionally use Typed Clojure syntax for special cases. It also makes the most sense to me --- malli/spec/schema have the perfect syntaxes for generation/validation/conforming, they're just missing the static checking aspect. If we required type syntax everywhere, you'd either need to duplicate everything, or have Typed Clojure support all those things.

It should be pretty easy to make a spec1 "type provider" for Typed Clojure. The main problems are deciding good mappings for s/keys and s/fspec. I still don't really know tbh.

I guess you could just expand an s/keys into a huge HMap with all the namespaced keys in the registry as optional keys.

But :req/:opt isn't a first class concept in the type system.

Static type checking using spec1 specs https://www.patreon.com/posts/64321657 Thanks @rayatrahman9 for the idea!

Something I thought of, having read the above and also your thoughts in announcements, @ambrosebs, was a project recently where I overhauled an OOP-heavy web framework+ORM from vanilla JS to TS. Of course, actual data is not "typed", but the killer thing that made that once-opaque project flourish with intellisense, corrections, static error analysis and even spelling correction, was that it also realistic, opt-in and included validation. What made it happen so pleasantly was A => Typescript's gradual, structural, hyper flexible type annotation system, but also B => a library called zod ( or rather a fork called myzod ) Myzod was instrumental to make a lot of the bespoke validation logic that had been written by hand into easy-to-grok, manipulatable js objects. More importantly Myzod had dead-easy TS type <-> MyZod schema conversion, minus the obviously "semantic" specs like numerical value checking etc. Thinking back to that experience made me very excited about your recent endeavors wrt. spec/schema/etc. So I'd love to know how you're trying to answer the question of "which subset of spec/schema/etc ought to be available in core.typed?"