<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
Sean Hinde wrote:
<blockquote TYPE=CITE>It may be useful to share some of our findings here
at One2One on using
<br>Erlang for some reasonably complex jobs..
<p>Most common causes of bugs not found until runtime:
<p>1. Referring to a non existent external function.
<br>2. Mistyping (i.e. fingers not Type!) of atoms used as tags in either
<br>receive clauses or case clauses.
<br>3. Printing Strings. The io[_lib]:format commands require you to know
<br>string is a string type before using %s to print it without double
<br>otherwise it crashes. In a weakly typed language with no efficient
<br>is_string/1 this is a royal PITA.
<p>These cause problems most in weird error capture cases which may have
<br>been executed during testing (surely not). My personal favourite is
<p>We have not tended to have problems with adding Integers to Atoms or
<br>such things which type systems protect against.
<p>One could think of possible solutions to these three which do not involve
<br>full type system.
<p>1. A tool to go through a system and root out external reference problems
<br>(admittedly difficult to deal with apply(M,F,A)) would help. It would
<br>be nice when loading a piece of code into a running system to get a
<br>which included some indication of whether all the external references
<br>resolved, or even an option which would only load the new code if this
<p>2. I guess any solution to finger trouble in atoms is getting towards
<br>proper type system. Maybe something which could be declared at the
<br>a module which restricted the set of atoms which could be defined in
<br>source for that file would do 80% of the job. Language Guru help needed!
Another solution for this one is to use macros instead of atoms
<br> ?Message ->
<br> Any ->
<p>This way any mistypes are spotted by the compiler, very usefull in genservers
with a lot
<br>of state atoms
<br>3. Well, a string type would help!! Barring that to implement something
<br>in Java (ironically strongly typed) where you can send any rubbish
<br>System.out.println and it will do its best to format it in a nice readable
<br>form without adding extraneous " for example. The current C derived
<br>typed language %d%s is to me something of an anachronism.
<p>Having said all that we have had two large systems in service now for
<br>several months and not had a single outage.
<p>> -----Original Message-----
<br>> From: Thomas Arts [<a href="mailto:firstname.lastname@example.org">mailto:email@example.com</a>]
<br>> Sent: 23 August 2000 07:44
<br>> To: James Hague
<br>> Cc: firstname.lastname@example.org
<br>> Subject: Re: typing
<br>> James Hague wrote:
<br>> > >are there already some feedback on that approach ? is it
<br>> "academic" or
<br>> > frozen ?
<br>> > >used in projects?
<br>> > I asked this not too long ago. The response was that the
<br>> type system was a
<br>> > cancelled project.
<br>> Well, the projects that tried the typesystem were canceled,
<br>> that's what I
<br>> wrote. The typesystem self is more in a frozen phase. Some experiments
<br>> are going on, but on a low priority level. The problem is
<br>> that Erlang has
<br>> not been designed with a type system in mind. Adding one
<br>> later is possible,
<br>> but at a certain cost w.r.t. the freedom of programming. We
<br>> are investigating
<br>> whether we can find an acceptable compromise for things to give up.
<br>> However, I can recommend everyone to start using teh SpecWeb
<br>> software in
<br>> order to make the datatype specifications. This is useful even without
<br>> a checking program.
<p>NOTICE AND DISCLAIMER:
<br>This email (including attachments) is confidential. If you have
<br>this email in error please notify the sender immediately and delete
<br>email from your system without copying or disseminating it or placing
<br>reliance upon its contents. We cannot accept liability for any
<br>confidence arising through use of email. Any opinions expressed
<br>email (including attachments) are those of the author and do not necessarily
<br>reflect our opinions. We will not accept responsibility for any
<br>made by our employees outside the scope of our business. We do
<br>the accuracy or completeness of such information.</blockquote>
Tony Pedley <A HREF="mailto:email@example.com">mailto:firstname.lastname@example.org</A>
Ericsson Intracom Ltd. Intranet : <A HREF="http://intracom.ericsson.se">http://intracom.ericsson.se</A>
1 Bede Island Internet : <A HREF="http://www.ericsson.co.uk/datacom/index.htm">http://www.ericsson.co.uk/datacom/index.htm</A>
Leicester memoID : ECOM.CBERAM
England Tel : +44 (0)116 2 542 400
LE2 7EU Fax : +44 (0)116 2 046 111