typing

[Thomas Arts]

Sean Hinde wrote:
> 
> It may be useful to share some of our findings here at One2One on using
> Erlang for some reasonably complex jobs..
> 
> Most common causes of bugs not found until runtime:
> 
> 1. Referring to a non existent external function.

A type system that only examines module-wise cannot help you here.
But this error is easily found by building the function dependency
graph.

> 2. Mistyping (i.e. fingers not Type!) of atoms used as tags in either
> receive clauses or case clauses.

This seems a trivial error, but in its full extend, it is hard to see
that an atom is mistyped. In particular when a message is received, it
is hard to find out what the allowed syntax of the message may be.
The only thing that may help here is having a message specification and
check that against the receive statements. If it is nothing but atoms
one wants to check, it suffices to specify the messages as regular
expressions with atoms in it and try to match with the receive statements
in a module. Problem here is that modules do not need to correspond to
processes...

> 3. Printing Strings. The io[_lib]:format commands require you to know that a
> string is a string type before using %s to print it without double quotes,
> otherwise it crashes. In a weakly typed language with no efficient
> is_string/1 this is a royal PITA.

why do you need an efficient is_string/1? printing is inefficient anyway.

> We have not tended to have problems with adding Integers to Atoms or other
> such things which type systems protect against.

I personally make these classical type errors, though not with atoms and
integers, but with list of lists where I only use a list of depth one and such.
Writing [] instead of [[]] for a base case...
 
> One could think of possible solutions to these three which do not involve a
> full type system.
> 
> 1. A tool to go through a system and root out external reference problems
> (admittedly difficult to deal with apply(M,F,A)) would help. It would also
> be nice when loading a piece of code into a running system to get a result
> which included some indication of whether all the external references were
> resolved, or even an option which would only load the new code if this was
> true.

one should not use apply/3 and if one does, don't complain about errors that
are hard to find. What about the cross-reference tool xref ?
 
> 2. I guess any solution to finger trouble in atoms is getting towards a
> proper type system. Maybe something which could be declared at the start of
> a module which restricted the set of atoms which could be defined in the
> source for that file would do 80% of the job. Language Guru help needed!

A separate file stating 
Messages formats used in this module:

{tag1,*,*,tag2,*}
{tag3,*}
tag4
{tag5,*,*}

together with a small addition to a parse tool would do. But it won't prevent
you from calling a process with {compute,16} and receiving {compute,X} when list(X) ->
 
> 3. Well, a string type would help!! Barring that to implement something like
> in Java (ironically strongly typed) where you can send any rubbish into a
> System.out.println and it will do its best to format it in a nice readable
> form without adding extraneous " for example. The current C derived mini
> typed language %d%s is to me something of an anachronism.

Adding a string type is something one needs to do in the runtime system. I don't know
why this hasn't been done. The booleans should have had their own type as well.

> Having said all that we have had two large systems in service now for
> several months and not had a single outage.

which is nice... probably it is not only typing that counts ;0).

/Thomas