🚀 go-pugleaf

In article <754@gould.doc.ic.ac.uk> phjk@doc.ic.ac.uk (Paul H J Kelly) writes
lots of good stuff about Occam's continued nonwidespreadedness.

One other thing that would have helped, i think, is to have made it easier for
folks to roll their own occam systems.  occam was exactly i needed for
a project a while back (i think; i didn't try it so i might still be wrong)
namely programming a pile of parallel dsp's in a hi-level language.
i was trying to make a compiler for a 16-bit integer-only subset of occam.
"OCCAM" it wouldn't have been exactly, in the sense that your occam programs 
wouldn't run on it, but in most respects the same.  and the dsp world
very much needs this right now, IMHO.

i never could even seem to find a complete definition of the language (till
after the project was cancelled) and so all during the period i was trying
to build a parser for it i kept finding new code fragments (examples in
newer inmos books) that i hadn't anticipated, like IF expressions for example.
(I would have called it SPOcc (Signal Processing Occam) cute, huh?)

so if I had some new language that i wanted you to use, (i'd make it good
etc. of course... i'd give it records/structures like Mr. Kelly mentioned,
i'd MAKE IT RECURSIVE like God intended) and==>i'd give you a FREE C
implementation of it or at least of a compiler front-end<==that's what'd do it.

i know there was a "portakit" but it was unavailable when i needed it.

that's what Xwindows is doing, and maybe why it's more widespread;
the X consortium created a public domain implementation (i think).

despite its problems, i'm still kind of infatuated with occam.
the trick of proving that the T800 FPA was equivalent to the (IEEE 
compliant) T414 FP library is very slick.  the TN on "compiling
occaminto silicon" is provocative in my opinion.