🚀 go-pugleaf

re :-
>Occam is the greatest thing since sliced bread

>No it isn't. I prefer C 

>C is terrible - OCCAM is best although I'm very impressed by SQURGLE-III
>running on the Zamba-weeny multi-folded-memory machine ($1.5million, only
>one delivered) (smug-in-the-know-inward-chuckle)

Having just written what amounts to an Occam interpreter (with additions) in
C I can see both sides of this argument. However I think it would be best
if everyone would simply agree that Occam is unfinished and that data
structrures and recursion will eventualy be added - if Inmos won't someone
else will.

The problem as I see it is how do you implement a memory allocation system
on a linear memory machine, which will cope with a highly parallel 
language without spending all your run-time doing garbage collection ? If
someone could sort this one out then we could implement Occam properly.
The real issue is about recursive data structures. Recursive function calls
without recursive data structures are fairly pointless - about all you can
do is implement the factorial function very inefficiently (I bet someone will
now find an obscure exception...). While were at it we could also require
the ability to specify arbitrarily large parallel processes, ie

     ....
     SEQ
       c ? e
       PAR i = 0 FOR e -- 
         ....
Also if we allow user defined data type then we should also allow the 
programmer to specify replicators which scan them e.g.

     SET OF numbers  set:
     c ? set
     PAR i IN set
       ....

The essential point as I see it is that any additions to Occam must not 
increase the complexity of the root language - only the functionality. This
might be achieved by removing the standard FOR replicator from the main
language declaration and replacing it with some form of replicator constructor.
The FOR constructor would then be avaliable as a standard library function.

Similarly if the user is allowed to specify new types she must be put at no
disadvantage to the compiler writter. For instance I might write a program
to deal with some (unspecified) operation on polynomials. In most languges 
addition of two polynomials would require a function call :-

	POLY a, b:
	a := add (a,b)

However appart from inconvenience to the compiler writter why not allow the
call to be made :-

	POLY a, b:
	a := a+b

The reservation of infix notation for inbuilt functions does not to my mind
increase the elegance of the language - in fact is should be regarded as a
complication. I admit that this scheme involves operator overloading - but
so what ? we already have it since + can have the types :-

	INT -> INT -> INT
	INT16 -> INT16 -> INT16
	INT32 -> INT32 -> INT32
	REAL32 -> REAL32 -> REAL32
	REAL64 -> REAL64 -> REAL64

so why not 
	COMPLEX -> COMPLEX -> COMPLEX ?

To sum up, if you want to write code now C is probably the better bet - although
using pascal might be rather more respectable. However if the transputer
had been launched without Occam the bussiness of real MIMD processing would
probably never have started. C is all very well if you are running a farm with
little interprocessor communicaton - but if you want real parallelism you
will probably end up either using Occam - or hacking up C so that you have
Occam-like channels and rendezvous (or buying one ready hacked).

		Phillip Hallam-Baker

Oxford Nuclear Physics Dept
Zeus project 

P.S. Disclaimer : Almost no-one else in this department would agree with a
     single word of this - but they all use FORTRAN.