🚀 go-pugleaf

In article <MICHAEL.92Nov16185558@lucrece.uk.ac.oxford> michael@uk.ac.oxford.robots (& Stevens) writes:
>Now the arguments about recursion and OCCAM have been going a while I
>though I would make a quick summary.
>
>FOR recursion:
>	1. Recursion is mathematically elegent. Serious software
>engineering requires it.
>	2. Code generation isn't hard. Handle the stack extension is possible.
>If it can be done for C, you can do it for OCCAM.
>	3. You don't need to use it. If you want to be able to
>predetermine memory usage at compile time don't recurese.
>	4. Why single out memory as the single resource that should be
>predetermined at compile time. Time is another resource that runs out,
>and so does disk space.
>
>AGAINST recursion:
>	1. OCCAM 2 doesn't do it.
>	2. Its not implemented in OCCAM 2.
>	3. Thats all I can think of, but I am sure it has something to
>do with OCCAM 2.
>
>Personally I think the arguments against have it :-)
>
>Ok enough humour, how about the even tricker issue of dynamic memory
>allocation. Does OCCAM 3 need it as part of the language? Should OCCAM
>3 have type safe pointers? Or should we be content with INT32 and
>library procedures to allocate memory?
>
>Would all this overburned OCCAM and turn it into yet another hacked up
>language like C?
>

Three years ago I wrote a large program in Occam2.

After writing some stack based utilities using arrays in Occam to
allow simulated recursion. This took time to develop.

Nowadays I use Inmos Parallel C which is a far more usable language.



-- 
Email: N.H.Thomas@cs.bham.ac.uk     G7ABW
Work:   Fax: +44 (0)21 414 4281     Tel: +44 (0)21 414 3736
Home:   Fax: +44 (0)21 454          Tel: +44 (0)21 454 5729
Mobile: +44 (0)891