| Hi David, Rick I agree completely that priority is not the priority, by a long chalk; it is how to program large numbers of processors. While I doubt this is entirely a language issue – there is a desperate need IMHO to introduce apprenticeship in programming, as well as programming within schools, where at least a start has been made – we may need to raise the level of abstraction. I'd beg that we strive to achieve an even greater degree of security and transparency than occam had, and that we address the need for 'packaging' (what someone at Inmos called "project modularity" (promoting reuse), as well as "system modularity" (affording (de)composition) without clutter. With Honeysuckle, I proposed layering instead : define components and interconnection separately (documenting a design), and then require that implementation refines it. Honeysuckle also proposed raising the level of abstraction from channel to 'service' – a protocol defining how communication proceeds. I know deadlock is not the only demon that threatens parallel programs, but IMHO it remains the most insidious and arguably the biggest deterrent. Adopting server/client architecture at the root level does not introduce any additional work or restriction, but effectively slays that demon. (A service can reduce to a mere channel.) This does not preclude allowing "cyclic ordered processes" (as Dijkstra called them), which can be safely connected to a c/s network, and are deadlock-free. The final major addition in Honeysuckle was recursive data types, allowing dynamic lists and trees. I woud love to partake in any meeting on an occam successor. Please keep me listed! Ian PS A Honeysuckle draft manual, plus archive of papers can be found here. (I regret there is no compiler. I devoted my time to the design of the overall language.) On 4 Oct 2012, at 23:51, David May wrote:
Ian East Open Channel Publishing Ltd. (Reg. in England, Company Number 6818450) |