[erlang-questions] Intel Quad CPUs

[Tobias Lindahl]

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 
the tests.

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.

Best,
Tobias