On 27 September 2012 14:04, Ruth Ivimey-Cook <ruth@xxxxxxxxxx> wrote:
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.
I wholeheartedly agree.
Â
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.
An interesting idea. From my limited understanding, it looks like targetting CLR would be worth researching further, whereas we know from unhappy experience with threads in Java et al that the JVM would not be a viable target.
Rick