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

[Ruth Ivimey-Cook <ruth@xxxxxxxxxx>]

Rick, Ian

I love occam for the power and capability of it's parallel constructs, 
but also found the limitations it has as a sequential language very 
limiting. I can agree that a "proper" multi-stage loop is a lovely thing 
to have (in the absence of goto or break) and also that there are 
serious issues with more advanced data structures. IMO occam-next must 
support at least lists and sets of things as a fundamental type. It 
would be good if the language were capable of expressing other types, 
e.g. b-trees, ring buffers, and compound types: b-trees of lists (aka 
hash table), et al.

What I would be interested to see would be if a computer languages 
scientist can bring some of the power and flexibility of, say, the C# 
Class and Interfaces structures into one language with Occam's parallel 
constructs. Does that necessarily and automatically break the use of 
occam as a formal language?

In fact, I think it would be a Good Thing if it were possible to build 
occam as a first-class client of the .NET CLR, which would then mean you 
could intermingle a huge raft of code, much of which is portable, with a 
language that supports good paralelism. I did this, to an extent, when I 
used JCSP via J# for a .NET application, and successfully in my opinion. 
The downside with that is it used the heavy native J# threads. A CLR 
implementation may enable the creation of better, lighter-weight options.

Just some thoughts,
Ruth

--
Software Manager & Engineer
Tel: 01223 414180
Blog: http://www.ivimey.org/blog
LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/