[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Occam-Tau - the natural successor to Occam-Pi - or is there one already?

Caveat – I am not a real programmer, so my views should be taken with a pinch of salt.


I came to Occam from programming real time systems in assembler on 2-4k ROM memory systems. What I liked about the simplicity of Occam was that with PAR and PRI I was easily able to describe the things that I had had to write management routines to do previously – the typical car engine controller has foreground tasks driven by the engine turning and background tasks, such as engine temperature, throttle setting.


If we want a parallel programming language for kids to learn with, in my view it should be simple and have the basic concepts – ideally we would have a language with two variants – a subset for learning and an enhanced version for serious programming.



Tony Gore


Aspen Enterprises Limited email  tony@xxxxxxxxxxxx

tel +44-1278-761000  FAX +44-1278-760006  GSM +44-7768-598570 URL: www.aspen.uk.com


Registered in England and Wales no. 3055963 Reg.Office Aspen House, Burton Row, Brent Knoll, Somerset TA9 4BW.  UK




From: Mailing List Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Ian East
Sent: 01 October 2012 09:28
To: David May
Cc: Larry Dickson; Ruth Ivimey-Cook; Occam Family
Subject: Re: Occam-Tau - the natural successor to Occam-Pi - or is there one already?


Hi David


I think the most important thing you said (slide 33) was that kids "should learn about Sequence, Concurrency and Event-handling (interaction) at the same time". This means getting in early, before the rot sets in.  Once anyone has mastered all the nonsense and accepted it, and allowed their ego to profit from penetrating the obscure notation, you've had it.  They never go back.


The recent arrival of a far better GCSE Computing (OCR), where programming is at last included, and without reliance on any single PL, is an opportunity.  There is instead a reliance on pseudocode.  Simon Peyton Jones appears to have influenced things.  Perhaps a nudge here might see the pseudocode extended to include a parallel and ALT construction, along with communication primitives.


That leaves prioritisation, which IMHO is as important, and I've never felt happy with PRI PAR and PRI ALT, particularly with the combination.  Badly missing prioritised vectored interrupts, which I grew up on, I proposed a 'when' construct for Honeysuckle, affording pre-emption.  The trouble with that is that its component processes are more sequential than parallel, and must communicate somehow.  All I could come up with was shared variables, with a little protection back from restricting assignment to one process each.  There is some basis for this in Tony Hoare's original book, in his 'alternation' operator, but nowhere near enough.  I'd really like to see a debate resume on what sort of prioritisation construct we need, and how to manage pre-emption.  Theory is lacking, but I don't think we can wait for more.


I completely agree we are facing an exponentially worse situation wrt software development given the exponential rise in core count.  We must begin with the youngest, I think.




On 30 Sep 2012, at 11:42, David May wrote:

Dear all, 


I've just noticed this email trail. It reminded me to post a keynote presentation 

I gave recently - it's here:



It was given at a "Multicore Challenge" conference in Bristol last Monday. 


Unfortunately they lost the recording so you have to guess what I said!


The main thing I've realised over the last year or two is that if you want to

write efficient programs for huge numbers of cores, you have to think about

the pattern(s) of communication. And of course, the language(s) have to be

able to express them clearly; the compilers have to be able to analyse

and optimise them; the architectures have to be designed to support them. 





Ian East

Open Channel Publishing Ltd.

(Reg. in England, Company Number 6818450)