Re: Occam-Tau anyone???

[Michael <sparks.m@xxxxxxxxx>]

On 5 October 2012 10:04, Jeremy Martin <jeremy.m.martin@xxxxxxx> wrote:
> Hi David,
>
>
>
> Sounds like that could be a great initiative! Would you consider overhauling
> the syntax of Occam to make it more appealing to current programmers? For
> instance, how about making a variant of Python with Occam constructs, since
...
> Python is a mainstream language which is syntactically similar to Occam, and
> which currently suffers from lack of support for parallel programming?

There's lots of libraries in python supporting parallel programming.
Some of which are inspired by things like occam some from other
approaches.

> I don’t think Python has any proper formal semantics

The python language definition isn't a formal semantic definition of
the kind you'd use for a proof, however, it has been precise enough to
allow implementation of a executable formal specification of the
language in Haskell.

The only reason why people think python isn't good for parallel work
is really because of the impact of the GIL vs mixtures of IO bound and
CPU bound threads. The GIL however is there primarily to protect
C-extensions, and in particular protect C-extensions developers from
otherwise easy to make mistakes.

There's work going on inside the PyPy project aimed at replacing the
use of a GIL with STM instead, and this is making good traction.

If you're going to think about merging python and occam, understanding
why the GIL is there, what it's for (protecting shared object based
extensions), and how you would support that is the place to start.

Otherwise, most python developers will continue to use the existing
multiprocessing, threading and greenlets libraries for handling
concurrency and parallelism, since they're driven by pragamtism, not
purity.

> so the new language
> would have to build on Occam for that purpose, and some of the python syntax
> might have to be dumped if it couldn’t be expressed in Occam.

If you're dumping the python syntax, you'd be better off extending Go.

</tuppenceworth>

Michael.