[erlang-questions] When can an integer > 0 not be a pos_integer() in the Dialyzer?

[Kostis Sagonas]

Foolish Ewe wrote:
> Hi Kostis:
> 
> Wow that was fast :-).  Speaking of fast, am I imagining things or is the
> dialyzer noticeably faster when using it in R12B4 than R12B3,

Frankly, I do not remember.  We try our best not to slow down Dialyzer 
as its code evolves and correct performance bottlenecks that we become 
aware of.

Despite that, regarding the speed of Dialyzer, I find myself having 
similar feelings to those I have for my salary.  It's sufficient for 
allowing me to live more or less comfortably with it, it improves a bit 
as time goes by, but it's always considerably less than what I would 
like it to be :-)

> Thanks for the quick response.  I should have been a bit more thorough 
> in reporting the command line options I used, I'm sorry about that.
> My gut reaction is to turn on the strictest
> possible checking in any static analysis tool, I'd much 
> rather sweat it now than be chasing run time errors later.

Generally this is a good approach, but the problem in what you did is 
that you turned on options with contradictory aims: -Wunderspecs warns 
about specs whose constraints are not as strong as they can be (and you 
probably want to constrain the uses of some of your functions), while 
-Woverspecs warns about specs whose constraints are stronger than what 
can be inferred.

In general, you want to use -specs that impose stronger constraints on 
your functions than what your function allows. For example, for the 
function:

   app([], L) -> L;
   app([H|L1], L2) -> [H|app(L1,L2)].

whose success typing is:

   -spec app(list(), any()) -> any().

(i.e. it requires a list in its first argument, accepts any term on its 
second, and can return any Erlang term), you probably *want* to use an 
less permissive spec like the one below:

   -spec app(list(), list()) -> list().     % overspecified

(i.e. constrain the second argument and the result to be a list), but 
you do not want to accidentally specify a more liberal (overspecified) 
contract like:

   -spec app(any(), any()) -> any().        % underspecified

Note that I am using the new notation for specs available from R12B-4 
onwards.

Kostis