4 ms·

Ambrose is doing some super awesome work with Typed Clojure. I'm a big believer in pluggable, optional type systems. Hell, even recovering typeaholics are star

Ambrose is doing some super awesome work with Typed Clojure. I'm a big believer in pluggable, optional type systems. Hell, even recovering typeaholics are starting to believe that Gilad Is Right [1]. Ambrose has managed to get me excited about what types can do for me in dynamic languages without bogging me down. There's lots of cool things we can do with types without having them split our language in to two sublanguages (type and term languages), pervading our compilers and runtime environments, and preventing us from doing useful things. If you view types as yet one more tool in your verification toolbox, you gain a lot of freedom. Consider "Type Coverage" as an analogy to "Test Coverage". I shared that idea with Ambrose, and he jumped right on it! [2] With good, community standardized tooling, we can forgo forcing the type system in to our compilers and down the throats of ever programmer, but still reserve the option when we need more confidence in our code. So get behind types as a library and throw a couple bucks at Ambrose so he can continue his work! [1]: http://lambda-the-ultimate.org/node/1311 http://lambda-the-ultimate.org/node/1311 [2]: https://groups.google.com/d/topic/clojure/qiE7PP9uGKg/discussion https://groups.google.com/d/topic/clojure/qiE7PP9uGKg/discus...

vmind 13y ago
Making the type system pluggable and a separate pass also means you can do cool things like interfacing your type system with your database [1]. And the Heterogeneous and Value types mean you can be very flexible and precise with your requirements while also coding in a mostly idiomatic Clojure way. (Though things are obviously still raw or unimplemented, the base is looking good and shaping up quickly.) [1]: https://gist.github.com/c-spencer/6569571 https://gist.github.com/c-spencer/6569571 (just a PoC)
- moomin 13y ago
  Yes, although that's not the only wayh to do these things: F# has type providers, for instance. Although I've been burnt by C# web services and Hibernate often enough to be sceptical of the idea.
  - brandonbloom 13y ago
    Worth pointing out: Type providers, while awesome, are simply code generators that run interleaved with the type checking pass. What's happening in that linked Gist is a bit different: It's generating types signatures that are devoid of their own behavior. In order to recreate type providers (or Hibernate-like things), you'd also need to give a type as a parameter to a macro for code generation. Since you can invoke the type checker at anytime, you can interleave code generation and type checking in much the same way as F#. I don't think it's a good idea to generate code and strongly coupled types at the same time. An alternative approach would be to take some common source data structure, generate code and then generate types to validate that code. Those are two separate transformations, not one like with type providers. Type providers mean that type checking, compilation, and execution are coupled. In this Gist, you could run the code with or without type checking and you could ignore the code generation completely and run type checking for internal consistency. Much more flexible.
deleted 13y ago
[deleted]

vmind 13y ago

Making the type system pluggable and a separate pass also means you can do cool things like interfacing your type system with your database [1]. And the Heterogeneous and Value types mean you can be very flexible and precise with your requirements while also coding in a mostly idiomatic Clojure way. (Though things are obviously still raw or unimplemented, the base is looking good and shaping up quickly.) [1]: https://gist.github.com/c-spencer/6569571 https://gist.github.com/c-spencer/6569571 (just a PoC)

moomin 13y ago
Yes, although that's not the only wayh to do these things: F# has type providers, for instance. Although I've been burnt by C# web services and Hibernate often enough to be sceptical of the idea.
- brandonbloom 13y ago
  Worth pointing out: Type providers, while awesome, are simply code generators that run interleaved with the type checking pass. What's happening in that linked Gist is a bit different: It's generating types signatures that are devoid of their own behavior. In order to recreate type providers (or Hibernate-like things), you'd also need to give a type as a parameter to a macro for code generation. Since you can invoke the type checker at anytime, you can interleave code generation and type checking in much the same way as F#. I don't think it's a good idea to generate code and strongly coupled types at the same time. An alternative approach would be to take some common source data structure, generate code and then generate types to validate that code. Those are two separate transformations, not one like with type providers. Type providers mean that type checking, compilation, and execution are coupled. In this Gist, you could run the code with or without type checking and you could ignore the code generation completely and run type checking for internal consistency. Much more flexible.

deleted 13y ago

[deleted]