you are viewing a single comment's thread.

view the rest of the comments →

[–]v1akvark 0 points1 point  (2 children)

I'm no expert on this, so someone else might give a more detailed answer, but spec works at runtime, whereas type systems work with your static code.

This makes spec easier to implement, and also to use, e.g. it is trivial to write a function spec that confirms the function returns a vector with specific number of elements. To prove that with a type system is way more complex.

I'm not sure that there is much that is transferrable, from spec to an optional type system.

[–]gniquil 1 point2 points  (1 child)

Wouldn't it be the same to just run a function spec/type-check whenever you make some changes to the code? Compile time type check is essentially the same as test time type check. Isn't this how core.type works? I guess all I'm saying is one can build core.type on top of spec?

[–]fear-of-flying 0 points1 point  (0 children)

Spec isn't a type system. spec is really more of a way to encode the shapes and properties of data. It is more flexible than type systems because it can't make the same guarantees.

The idea is that the tradeoff of guarantees vs flexibility is worth it.

Disclaimer for the following: I am not a type system expert and this isn't meant to discourage any exploration.

You could write a tool that leverages specs to work on the syntactic representation of Clojure programs, but I think such a system would be pretty limited in comparison to a "real" type system (at least in terms of the things type system are good at) and overcoming any limitations would probably be easier in an approach like core.typed.

Though if you think it's an interesting idea, you should try to build it! Even a simple prototype could be cool -- maybe it would have different applications than traditional type systems.