🚀 go-pugleaf

In article <5631@m1.cs.man.ac.uk> bane@vtx.ma.man.ac.uk) (M i c h a e l ;-) writes:
>
>PS: Do many people still use occam? I was told recently by a systems person on a
>transputer machine that nobody uses occam anymore...

Here at the University of New Brunswick (Canada) we have been working with 
Occam for the past 1-2 years. Most of the time on a project to 
implement systolic/wavefront arrays efficiently on multi-transputer machines.
We do have other interests as well.  Also, one of our graduate courses deals
with parallel computing; Occam/transputers forms a major thrust of this course.

My personal opinion (for what is it worth) is that Occam 2 has (in common 
with other languages) stengths and weaknesses.  That is why we do not have
one single global language I guess.  Occam is speed/code size efficient, easy
to code in; not as portable as other some of the other languages and not as
well known or liked in the community.  Example, some utility programs which
will be useful to our environment (or others perhaps) will be coded in C on
an MSDOS machine and then ported to the transputer. Q: Has anybody had problems
with doing this before? If I require advanced data structures, I will more
likely consider C than Occam.  Most other applications I would consider Occam 2
first (and then go from there).  

Why Occam seams to be looked down on (ref. your question mentions that sys.per
doesn't consider Occam important), I don't know.  Perhaps it is the     
*implementation* of Occam on transputers.  Transuters are powerfull little
creatures.  Parallelism on an individual statement by statement basis (low
grain) is not the transputer forte.  Consequently, a major advantage that
Occam has over C is nullified: that is, Occams ability to specify *mutural
indipendance* between specific code statements, code segments or processes.
It seams natural to consider the possibility of a multi-processor machine,
each node of which consists of a number of processing elements (perhaps 
smaller mimd type processors) where in parallelism at the various grain levels
can be used to advantage.  Even without this hypothetical machine, Occam does
allow *more information* to be coded into a specific code segment than many
other languages.  That is, the specification of process heirarchy (grouping) andmutural indipendence between the various groups.

IMHO (I don't usually post this much of ramble - must be the way I'm feeling
today)

General discussion to the network, specific inquiries can be made to
k3mi@jupiter.sun.csd.unb.ca  or  k3mi@unb.ca