Newsgroups: comp.sys.transputer
From: andyr@wizzy.com (Andy Rabagliati)
Subject: Re: OCCAM3 (was :- Revision of occam 2 Referenc
Organization: W.Z.I.
Date: Tue, 9 Aug 1994 21:31:27 GMT
Message-ID: <CuAEGF.2p1@wizzy.com>

Mark Debbage <md@pact.srf.ac.uk> wrote:
>Peter Ivimey-Cook (peteric@gonzo) wrote:
>
>: Anyone got any ideas *why* PAR is illegal inside a function. Was it just
>: too complex a case to support? Or is there a valid mathematical reason?
>: I understand that FUNCTIONS are supposed to be pure (side-effect free),
>: but adding PAR wouldn't affect this, surely.
>
>: Peter IC.
>
>If you have PAR, then you will want channels too. You can then build
>functions that deadlock.

Well, anyone can write bad code. There shouldn't be a law against it.
I would like to be able to declare a channel local to the function.

>If you have channels, then you will want alternation and maybe timers.

Well, I didn't say timers. Can't do without ALT though.


>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.
>
>If you like the formal side of occam, things like this really matter.

Out of my league, I am afraid. As it happens, I have never had an urge
to put PAR in my functions. I use WHILE all the time, though.

Cheers,     Andy.

--
In sunny Colorado,
Andy Rabagliati  .  andyr@wizzy.com  .  W.Z.I. Consulting  .  +1.719.635.6099

