🚀 go-pugleaf

In <2292@eagle.ukc.ac.uk> wgd@ukc.ac.uk (Warren Day) writes:

>I would very much like such a language that has all the things that
>parallelism prevents: recursion, pointers, dynamic memory and data
>structures.

I'm afraid you've lost me:  why do you think parallelism prevents
recursion, pointers, dynamic memory and (especially) data structures?
Parallelism may complicate matters, but it doesn't actually prevent any
of these things.

>and there appears to be quite an argument along the lines of Michael's "why
>don't you have it and just not use it when you don't need it", which as
>Roger Shepherd said, means having two compilations approachs (if I understand
>correctly).

Not necessarily.  A smart enough compiler system may well be able to
support recursion at a small price if used, but without any overhead if
not used.  This can be implemented by a smart linker, which uses a call
graph to locate recursion and inserts stack allocation and expansion
code where necessary.  If no recursion is used, no stack expansion code
is introduced.

>             Perhaps Inmos have a market for a family of occam languages,
>occam.par and occam.seq.

I don't believe it would be wise for Inmos or any other transputer
compiler vendor to have parallel and sequential versions of their tools.
It may make sense to provide compiler options to allow stack stacking
and expansion to be tuned, in the absence of aforementioned smart
linker.

The CSP paradigm as supported by Occam and PACT Parallel C is a very
powerful one, and is especially interesting with the support provided
by the transputer.  It is up to the implementation to avoid unnecessary
overhead.

Cheers. - Rob

--
     PACT                   Rob Kurver
    Foulkeslaan 87         rob@pact.nl
   2625 RB Delft     ph: +31 15 616864 
  The Netherlands   fax: +31 15 610032