[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?

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,

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