[erlang-questions] dialyzer is driving me nuts

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Tue Oct 18 20:35:10 CEST 2011

On Tue, Oct 18, 2011 at 19:57, Joel Reymont <joelr1@REDACTED> wrote:

> The first message can be summarized as
> barrier_start.erl:50: The specification for barrier_start:barrier_start/3 states that the function might also return {'stop',#game{},tuple()} but the inferred return is {'continue',#game{{},_} | {'skip',#game{},_}

One problem is the specifiction is not general enough:

-spec barrier_start(#game{}, game_ctx(), barrier_event()) ->
{continue, #game{}, game_ctx()};
                   (#game{}, game_ctx(), {'EXIT', pid(), _}) -> {stop,
#game{}, game_ctx()}.

Clearly, this specification says nothing about the return value {skip,
Game, Ctx}. Remember that a success type here states: "If this
function, barrier_start/3, returns, then its return value is of the
return type in the contract and the inputs were of the form specified.
The occurrence of the following application:

barrier_start(Game, Ctx, foo),

would reduce to {skip, Game, Ctx}, in violation of the contract.

> The second message is a beauty!
> barrier_start.erl:74: The call gamelib:join(Game::#game{},Event::#pm_event{pm_message::#pm_join{}},1) does not have a term of type #game{} (with opaque subterms) as 1st argument
> What in the world does it mean?

My guess is that gamelib:join/3 outright requires the types in #game{}
to be correct, whereas the barrier_start/3 function only needs it to
be of the right record type and doesn't care for the internals.


More information about the erlang-questions mailing list