Newsgroups: comp.sys.transputer
From: dbc@ecs.soton.ac.uk (Bryan Carpenter)
Subject: Re: OCCAM3 (was :- Revision of occam 2 Referenc
Organization: Electronics and Computer Science, University of Southampton
Date: 10 Aug 94 08:49:03 GMT
Message-ID: <dbc.776508543@caesar>

In <Cu9pM9.H7n@info.bris.ac.uk> md@pact.srf.ac.uk (Mark Debbage) writes:

> [...]

>If you have PAR, then you will want channels too. You can then build functions
>that deadlock. If you have channels, then you will want alternation and maybe
>timers. You can then build functions that give non-deterministic results. Yuk.

>Some people think that allowing WHILE inside a function was a pretty bad 
>move, since that allowed you to write live-locked functions. This means that
>there can be no guarantee that arbitrary occam expressions will ever complete.
>In CSP terminology, this means that occam expressions can diverge. Yuk.

You should also dissallow:

integer division, because you might accidentally divide by zero;

any other integer or floating point arithmetic which might lead to an
overflow (ie, +, -, *, etc);

arrays, because you might introduce a subscript-out-of-bounds error;

variables, because you might read an uninitialised value;

recursion, because it's too useful.

>If you like the formal side of occam, things like this really matter.

>Mark.

:-)

Bryan


