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