HALLAM@vax1.physics.oxford.ac.uk ("P.M. Hallam-Baker") (08/05/89)
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.
les@unicads.UUCP (Les Milash) (08/15/89)
In article <8908031551.AA12160@uk.ac.ox.prg> HALLAM@vax1.physics.oxford.ac.uk ("P.M. Hallam-Baker") writes: > >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. i think i know how to do this. i'd be happy to talk to you or whoever at whatever length you like about my idea. i can't see how occam or C require GC at all; data objs have unambiguous and finite lifetimes. ya just gotta get away from that stack, its top is a damned scarce resource. i agree with those that bitch about C's defectiveness, and those that bitch about Occam's uselessness as a HLL. i tend to think of "occam" as meaning "everthing occam could be, even if i have to do it myself". >P.S. Disclaimer : Almost no-one else in this department would agree with a > single word of this - but they all use FORTRAN. PPS disclaimer: probably no-one else in this company would agree with a word of this either; they're happy to manually wrestle with unspecified ordering of side-effects (it's called "C/UNIX machismo"). just another naive hothead Led Z. Milash