🚀 go-pugleaf

In article <1992Nov18.130407.12799@titan.inmos.co.uk> Stephen Doyle,
steved@lion.inmos.co.uk writes:
>I guess the 
>difference boils down to whether you want an ANSI C validated compiler
with 
>functional additions for parallelism and communications or an ANSI C
compiler 
>with non-ANSI language additions for the same. I would argue (from
customer 
>feedback) that OCCAM tends to be used along with INMOS ANSI C as this 
>provides you with a flexible environment for parallel/comms/sequential 
>programming with excellent diagnostics at compile and run time.
>
>Just to cloud the issue once more INMOS' soon to be shipping new
optimising C 
>compiler has a specific optimisation for tail call recursion i.e.
>
>void p (int q)
>{
>  ...
>  return(p(...));
>}
>
>in this case the workspace of p is reused as the function recurses,
also, 
>nested returns are omitted so that only one return is needed no matter
how many 
>levels of recursion take place.

The compatibility issues mentioned above make me wonder if such
an 'optimisation' is conform ANSI standards. Forgive me my ignorance,
but would such a procedure work in any implementation of ANSI C?
It guess this is a new feature of C. Perhaps a rather superfluous
thing to do as well. C has loops.

By the way, we are implementing a lazy functional language (Concurrent
Clean) on the transputer. The way to write loops in such a language is
by means of recursion as depicted above (there is no other way). Needless
to say that we have implemented this kind of 'optimisation'.

Marco