[erlang-questions] Intel Quad CPUs
Wed Sep 5 15:00:34 CEST 2007
Kirill Zaborski wrote:
> On 9/5/07, Tobias Lindahl <tobias.lindahl@REDACTED> wrote:
>> We will present the specification language and some of its interaction
>> with the analysis in Dialyzer at the Erlang Workshop next month. We have
>> a functioning system and have started to annotate the libraries in OTP
>> for testing purposes. There will probably be an EEP at some point since
>> we are hoping to have it included in R12B.
> I can't wait one more month so I'd like to ask some questions:
> when will be these specifications used during compilation or in
> runtime? (Runtime checks will require additional CPU time but with
> compile-time checks you can have problems with code update at least)
> What will be checked: function body or the parameters I supply for it?
The extension we suggest is a language to write specifications (or
contracts as we like to call them). The language is very similar to the
language of edoc, with the difference that the contracts are parsed and
live their lives as compiler attributes rather than comments.
The contracts should not necessarily be used by the compiler, but rather
for tools that can benefit from the kind of information that is given.
Obvious examples are Edoc and Dialyzer, and since we are developing
Dialyzer, our focus is slightly more aimed towards the type information
we benefit from.
The dynamic nature of Erlang limits the static checking of the contracts
somewhat, but our idea is to use the same philosophy as Dialyzer is
using. When a contract cannot hold this is reported, but otherwise it is
trusted as a promise given by the user. "I promise that this function
will be used in the way I specify. Please tell me if I missuse it."
Checking the contracts dynamically is probably costly, but we have
started a project to investigate how costly it is, and how it can be
used in instrumented systems for testing purposes. Perhaps it can be
used while running testsuites to find if the contracts are broken during
Also, I can imagine that the specifications can be used for test case
generations, it can probably be useful for QuickCheck, EUnit and any
other tool that can benefit from the information about how the user
intends the program to behave.
To sum up. The contracts are a way for programmer to express intentions
in a way that can be used for tools without having to parse human
language written in comments. The tools can then use the information for
whatever purposes they want, and also provide feedback to the user about
the contracts. The contracts will not (at least not in our proposal)
affect the semantics of Erlang, and the only effect on syntax is that
you are allowed to include contracts as attributes.
More information about the erlang-questions