Re: Rick's musings on modifications to occam

[Richard Beton <rdb@xxxxxxxxxx>]

Adrian Lawrence wrote:

> >     can have variable n, requiring workspace for each process to be
> >     allocated dynamically from the machine's heap.
>                                         ^
>                                         |
> Richard, aren't you giving the game away here?  :-)
> 
> You are thinking of a *single* machine on which memory managers might be
> implemented reasonably efficiently. Surely occam has the wonderful
> property that given sufficient parallelism, a program  - in principle at
> least - can run on any number of devices.
> Maybe a distributed manager might be implemented on some parallel machines,
> but it will certainly require great effort.

Let me give the game away by spelling it out :-) ... I am pressing
the changes necessary to make occam more at home in a Unix world,
clearly necessary if you accept Paul Singleton's blunt warnings. I
think dynamic memory can co-exist with static memory. occam would continue
to give static memory guarantees by default (and, in OS-less processors
such as transputers, that's all you get). Plus, occam would also have
access to OS-based dynamic memory for programs running under Unix for
those who want it. I don't think this is difficult to do (except
possibly on multi-sparc or multi-alpha SMP workstations - I'm not
so sure about these).

I am convinced the Unix development of occam should be a key element of 
the OFA project. Most of the tasks to be addressed are compiler and 
library issues, but dyanmic memory is a language issue. I'm not a
dynamic memory fan - I've written lots of occam for the transputer
without needing dynamic memory. But to coexist with other Unix
programs (and programmers), occam will need it.


> And you break the formal properties, although I suppose that we could
> add a Precondition about not running out of memory! Ugh.

Heap exhaustion is just another run-time error, like divide-by-zero
etc. At least in the proposed occam dynamic memory model, there would
be no memory leakage nor dangling pointers.


> But I agree that there is no question of doing anything major in the immediate
> future. But if we ever did tackle the vexed questions of dynamic process
> creation, recursion and memory allocation - which are surely all of a piece -
> then we will have to take a much longer harder look. Of course, all this
> was debated when occam was born.

They probably are all of a piece. However, we have already had dynamic process
creation for the last decade (except occam hides it from you). Recursion would
be difficult to add to occam and is of lesser benefit given that (almost) all
recursive programs can be mapped to iterative behaviour. That leaves dynamic
memory...

All the best,
Rick

-- 
              Richard Beton BSc MInstP CPhys
      Roke Manor Research, Romsey, Hampshire SO51 0ZN
-------  Standard disclaimer about my own views etc  -------
           See http://www1.roke.co.uk/WHR/WHR.html