Dialyzer type complexity limit
Wed Mar 17 00:20:43 CET 2010
Hi all (especially the dialyzer folks),
In running dialyzer over our code, we're striking what appears to be
the limit of type complexity. Specifically, we have a type which is
composed of 29 different possible atoms, but evidence suggests that
dialyzer is collapsing the type down to just atom(), since we can assign
any atom to record elements of that type without dialyzer throwing a
warning. That behaviour remains until I reduce the number of atoms down
to 23 at which point incorrect assignments are picked up.
I'm presuming this is the "union limit" referred to in the paper
"Practical Type Inference Based on Success Typings", though 23 atoms
seems (to my mind, at least) like a fairly small limit. I looked around
but couldn't find any specific details on what that limit is or how it's
calculated (since I understand that it probably wouldn't just be a
simple number when you're dealing with integer ranges etc).
So I have three questions:
* Am I right in my assessment of what's going on?
* Is there an "easy" way (for some definition of "easy"), either through
external configuration or in the source code, to adjust this limit? A
quick scan through the source code showed me only that the people who
wrote it are much smarter than me ;)
* Is it possible to get a notification or something when a type is being
treated more broadly than its strict definition?
More information about the erlang-questions