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

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

Hi folks

Just thought I'd add a reminder of my own proposal for an alternative path to occam-pi, in Honeysuckle.  (Draft document and past papers here.)

To my mind, the big things missing in occam were :
–  symmetry processes in sequence and parallel, with the ability to pass object itself over channel (mobile objects)
–  adequate support for data abstraction, including dynamic objects like lists and trees
(this means Hoare's (1975) Recursive Data Structures, including invariants, which eliminate the need for explicit pointers)
–  transparent support for project modularity, i.e. the use of pre-existing or separately developed code (replacing #USE)
–  support for binding specification and design, visual, textual or both  (guaranteeing refinement)
–  protection against deadlock via formal static verification (e.g. of client/server architecture)
–  (admittedly a pet vexation) a do-while-do loop, with multiple exits (I use 'em all the time, in pseudocode at least).

Honeysuckle addressed all of these, at least as a proposal.  Producing a compiler is somewhat costly, as it adds yet more static verification.  (I still plan to implement one but that has to wait until I've finished home-educating my two boys – another four years, so it's open to anyone else with an interest.)

Note that I do not share an enthusiasm for anything else mobile beyond objects.  I believe that the model for abstraction represented by a language must be both accessible to a large community, to provide adequate recruitment, and be sufficiently transparent to eliminate as much opportunity for error as possible, even among "black-belt" programmers.  In other words, be a lot more like engineering of hardware, bridges etc.  The proportion of students I have encountered who would stand any chance of getting mobile processes and channels right is vanishingly small – even smaller than the proportion who could be trusted with pointers.

I noted this last CPA that the Kent team plan to implement recursive data types.  I raised the issue of just how programmability compares with pointers, but was slapped down by Peter.  While I'm well aware of how one programs lists and trees this way (without pointers), issues still remain.  I've just implemented an AVL tree ADT and can't help wondering how I'd do tree rotations without pointers.  I think I could do it, but it's certainly unfamiliar, and might be a hard sell to many.

Lastly, I think we should be well aware of the cost to our mission of allowing the perception that we're in conflict with traditional OOP.  It's certainly the case that there is hostility among some of us, but this is an image we cannot afford, and we have certainly failed to address the biggest weakness in our flagship language, occam – that it does not support the construction of anything more ambitious than a simple record or array, and is therefore unsuitable for a host of applications.

Very best

On 26 Sep 2012, at 22:55, Rick Beton wrote:

Hi friends,

I've been reading through papers from Abertay with the usual mixture of cheerful excitement and a little frustration that there's more we could do. So...

I've been jotting down thoughts on a new version.  I called it Occam-Tau coz the idea of Tau (=2*Pi) representing wholeness, a completion of a turn, a full circle, makes it the natural successor to Occam-Pi (which is dare I say, tongue half in cheek, "half-finished"?!). 

Occam-Pi brings maturity to the good ideas on concurrency. Most of the bases are covered. Job done...  Well, only "half" done. If you want to include some sequential code in Occam-Pi, it's still, frankly, the same mess it was in back in the '80s.  Occam-Tau is about the completion of that circle.  

Can we have a language please that is capable of both small scale and large scale projects?

My thoughts are written down on my Google Drive which I will share and invite you to comment on.  Let's make this a discussion about the language.  But more so, let's also make this a discussion about implementation - ideas are fun but fruitless without implementation.

I look forward to your comments,
Rick Beton

Ian East
Open Channel Publishing Ltd.
(Reg. in England, Company Number 6818450)