Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!pt.cs.cmu.edu!cat.cmu.edu!jps
From: jps@cat.cmu.edu (James Salsman)
Newsgroups: comp.sys.transputer
Subject: Re: choosing parallel languages
Message-ID: <5726@pt.cs.cmu.edu>
Date: 2 Aug 89 01:20:47 GMT
References: <8908011650.AA12679@kanga.cs.umass.edu.edu>
Organization: Carnegie Mellon
Lines: 44

In article <8908011650.AA12679@kanga.cs.umass.edu.edu> oskard%kanga@cs.umass.edu (DAVID OSKARD) writes:
> 	If you had the chance to do it all over again, would you buy
> Occam or one of the third party compilers for the Transputer?

Occam is far superior for multiprocessing than any serial
language (such as C) and it's model is much more safe and
effective than Ada's.  The problem is that the C-weenies
of the world have not yet aquired the brain capacity to
understand the beauty and functionality of Occam -- yet.

The only thing I would change is to allow value functions
to be recursive and specify that tail recursion is properly
dealt with (as in Scheme.)

> To me it seems that the lack of support for data structures in Occam
> is in itself reason enough to consider other possibilities. Is this
> really as big a deal as it seems?  How have you gotten around Occam's
> limitations?

Hey!  How about "Procedural Abstraction?"  What a concept...

The lack of dynamic memory allocation in Occam is easily
overcome by allocating a large array, and using procedures
for allocation and freeing of individual elements.  If you
do it right, and know how to use the retyping system, you
can create a generalized heap storage system, where the same
memory is used to store many types of data.

The macho way to do it is to create a tagged protocol
channel coprocess that allocates memory and handles access
and (de)allocation functions.  Then, you can place the
process on whatever processor has the RAM (or the disk) for
the data that you're storing.  This is a cool programming
technique, as well as a neat abstraction.

:James

Disclaimer:  The University doesn't always agree with me.
--

:James P. Salsman (jps@CAT.CMU.EDU)
-- 

:James P. Salsman (jps@CAT.CMU.EDU)