To fix these issues, Chris created a library called Norm:
The idea is for this library to serve as a library that validates your data’s format. I get the idea from the talk that this is supposed to be a replacement for Dialyzer, but with a ton of additional features in the future (such as precondition and postcondition checks) and decent error messages.
Question
However, I don’t understand how this is supposed to replace Dialyzer. With dialyzer I am just adding an annotation and then it works. With this I can’t add annotations, I really am not sure how I would/could replace Dialyzer with this.
Has anyone tried this library?
How would you use it to replace Dialyzer annotations? Any samples would be welcome!
This reminds me a lot more of Clojure’s spec than Dialyzer, especially with the close connection to property-based testing.
I don’t immediately see how it could outright replace Dialyzer - It certainly could handle the “validate the shape of incoming parameters” part, but then there’s things like checking case statements for completeness and behaviour contracts.
I don’t think norm is meant to replace dialyzer in any way at all. I rather feel both are means to the same end: Detecting problems with data passed around. Dialyzer does do it by checking that via a type system. Norm on the other hand does it by validating data at runtime. It’s just a syntax thing that it’s also using the typespecs for its defintions. In the end it’s a matter of tradeoffs you want to make to decide which one is more useful for you.
But how would you use Norm to validate if a function is getting the right input and returning the right output?
Such is not clear to me in the documentation, thus all the confusion. The Norm VS Dialyzer competition is what I understood from the talk Keathley had in the podcast. If I misunderstood I would love to get some rectification. Right now Norm is in a fuzzy land for me, don’t really understand its use case beyond doing data validation plugs.
Something that ‘could’ be a dialyzer replacement would be something like my TypedElixir project if I actually got time to work on it again (I wish someone would replace it, *hint*hint*), but this does not seem to be even remotely in the same vein as dialyzer.
There’s some misconceptions here so I’ll try to clear those up.
My goal isn’t to replace dialyzer. My goal is to build a system that allows you to validate any elixir data at any point in your stack.
I explain these in terms of dialyzer and types because those are things that people already understand and the juxtaposition helps me make my point.
For me, Norm can’t replace dialyzer because I don’t use dialyzer in the first place.
Yup. Its going well.
This is actually possible with Norm (assuming your matching on the shape of your data).
Yup.
Norm doesn’t use typespecs for definitions. We do understand guard clauses though.
Alternatively, you can use both. Norm allows you to express properties of your system that Dialyzer can’t and will never be able to do. There’s no problem using both of them together.
You call conform! or valid? or one of the other predicates available to you.
You can validate data. That’s it. We’re working on supporting pre-conditions and post-conditions in Norm itself but that’s really just an extension on validating data. You aren’t limited to using these at function definitions. You can validate data wherever you want.
Thank you for the clarification! I also want to say I really enjoyed your presence on the show and that I sympathize with many of the Dialyzer points you made.
I know you don’t use Dialyzer in your projects, but do you have any recommendations for any tools capable of replacing it?
I am an author of Hammox, a library similar in spirit but different in execution:
It checks your function calls for conforming to typespecs at runtime, and the killer feature is that it works with mocks too, and works with code previously using José’s Mox out of the box.
This is likely better suited than Norm as a “Dialyzer replacement”, and I myself practically use it as such. But it still is a different tool operating in a different environment.
Nice lib you got there One of the killer features of Dialyzer for me is the @opaque type definition which allows to pattern match on it only in this module, and treats pattern matching on it in other modules as an error.
This is quite convenient for marking stuff as implementation detail.
One of the killer features of 
