| Hi Jeremy,
There is, or was, a thing called "Stackless Python" which started out as something CSP-like in the Python universe. By the time I looked at it (around 2009?) it had drifted away from this and was certainly no longer stackless.
I think the key point is not syntax but usability. (Python itself has unusual syntax, more like occam than C.) People want to be able to connect anything up and get it to work in fairly short order. You need a few friendly tools that allow you to "hook up" with working stuff in other languages, to script things together, and to let other people expand your model to their favorite configurations. I always thought one of occam's worst failings in the Transputer days is that the occam came to a dead stop at the "water's edge" of the host computer --- even though the device used to communicate with the PC host was a perfect link! I got so irritated at that that I wrote some PC assembly code that would do occam primitives and could link into the B008.
Larry 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? A similar thing to this happened when Handel became Handel C. I don’t think Python has any proper formal semantics 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. On the other hand it would be good if the huge body of contributed python code could be tapped into for users of the parallel version. Best wishes, Jeremy From: Mailing List Robot [mailto:sympa@kent.ac.uk] On Behalf Of David May
Sent: 04 October 2012 23:51
To: Rick Beton
Cc: Occam Family
Subject: Re: Occam-Tau anyone??? I would like to see an Occam-like language agreed, defined, implemented and promoted in an open process. I'm not interested in discussions about how to represent priority. There were several very good reasons why this was relegated to the 'configuration' section of the original language specification. In the meantime, nothing has changed. The occam-pi language is an over-extended version of occam with no formal specification. Some of the novel features have no efficient implementation in message-passing distributed memory So my suggestion is that we start form occam2, and look at what we need to add from occam3 and occam-pi. What is essential? I've been working on language issues for quite a while now - mainly looking at how we can really get value out of thousands Not sure how best to do this but I'd like to see it happen. I'd be On 4 Oct 2012, at 20:38, Rick Beton wrote:
Hi all, I started the original discussion following Peter's 'Occam Obviously' presentation, but sadly the language discussion petered out, lapsing into a fascinating but many-year-long rehearsed discussions on priority. My original hope was to seek an answer to this question: if the answer is Occam (obviously or otherwise), what will it take to make Occam generally usable? In its present form it is not so. Then there's the question of aspiration versus practicalities. The first suggestion I made was for packages to be added to Occam-pi and I put it first deliberately. Not a new suggestion, this; in fact Occam3 had 'modules' way back in 19xx (choose your own xx). I don't really care for the details of the implementation, I'm much more concerned that Occam-pi/-tau should belong to a busy community, inspired by (a) clarity of thinking and (b) a need to make things happen. If this is wishful thinking, then alas Occam is not obviously going ever to be more than a teaching tool.
This e-mail was sent by GlaxoSmithKline Services Unlimited
(registered in England and Wales No. 1047315), which is a
member of the GlaxoSmithKline group of companies. The
registered address of GlaxoSmithKline Services Unlimited
is 980 Great West Road, Brentford, Middlesex TW8 9GS.
|