[erlang-questions] dialyzer and behaviours

[Daniil Churikov]

(Sorry, initially replied directly)

Replying inline

> Whether a module conforms to a behaviour is something that
> can change either way when a new version of the module is
> loaded.  Being time-dependent, it can't be part of a type.

Whether a function returns an iolist or an atom can change with
a next version of code too. But you expect that dialyzer run will
reveal this spec incompatibility. So if next version of the module
will not implement behaviour it used to, why not to notify about
this?
I understand that this will not guarantee anything in runtime, you
still could load anything you want, but at least it could guarantee
me certain level of safety at dialyzer-run time.


2014-07-17 5:03 GMT+04:00 Richard A. O'Keefe <ok@REDACTED>:

>
> On 17/07/2014, at 12:56 AM, Daniil Churikov wrote:
> > Is there any way to write a spec for dialyzer that will tell that I
> expect module of certain behaviour?
>
> The types that the Dialyzer works with have no connection
> with the *state* of the Erlang system; it can only describe
> the shape of a term in and of itself.  Types do not vary
> with time.
>
> You cannot have "registered process name" as a type.
> You cannot have "defined key in the process dictionary" as a type.
> You cannot have "loaded module" as a type.
> You cannot have "open port" as a type.
>
> Whether a module conforms to a behaviour is something that
> can change either way when a new version of the module is
> loaded.  Being time-dependent, it can't be part of a type.
>
> This is not to say that *some* verification tool not utterly
> unlike a type checker might not be possible that could get
> closer to what you want.  It's just that time-dependent
> properties are not commonly thought of as 'types'.  Even in
> the languages I know about with dependent types, it's
> value dependency not time dependency that's in question.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140717/f451beb2/attachment.htm>