[erlang-questions] Dialyzer type complexity limit

[Kostis Sagonas]

Bernard Duggan wrote:
> 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?

More or less right, but I am a bit confused by your 23 -- I thought it 
was actually a bit less than that -- 13 to be exact.

> * 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 ;)

Yes, we are ;-)  We've succeeded in hidding this in a place nobody would 
possibly search for...  in a file called erl_types.erl.  Anyway, change 
the following line to a number you do not feel confident it matches your 
needs:

lib/hipe/cerl/erl_types.erl:-define(SET_LIMIT, 13).

and re-compile the file.

> * Is it possible to get a notification or something when a type is being
> treated more broadly than its strict definition?

The answer is "yes, of course it is possible" but doing this in the near 
future is of quite low priority to us.

Cheers,
Kostis