[erlang-questions] When can an integer > 0 not be a pos_integer() in the Dialyzer?
Sun Nov 16 10:01:54 CET 2008
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
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
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)
-spec app(any(), any()) -> any(). % underspecified
Note that I am using the new notation for specs available from R12B-4
More information about the erlang-questions