ConEuc? Concurrent Euclid (programming language)

[legacy]

Concurrent Euclid (also known as ConEuc) is a concurrent descendant of the Euclid programming language designed by James Cordy and Ric Holt, then at the University of Toronto, in 1980.

ConEuc was designed for

• concurrent
• high performance
• highly reliable

system software.

The TUNIS operating system is a Unix variant, and it was implemented entirely in Concurrent Euclid, this because ConEuc extends a core subset of Euclid with processes and monitors as well as language constructs needed for systems programming including separate compilation, variables at absolute addresses, type converters, long integers and other features.

Good theory, good book (see the Amazon link, the book/second hand is available for a few bucks), about practice … well, it "seems" ConEuc was implemented by a small (~k bytes?), fast, portable compiler that was self-compiling and had replaceable code generators, but I haven't seen sources around 

someone with a better experience here ?
I have bought that book and I appreciate it

[richardman]

I have the book, from the 80s! :-)

Good theoretical concepts. Holt is a brilliant mathematician. However, good languages based on good languages do not necessarily mean good general purpose programming language.

I think for concurrency, the "Future" construct may be the future, but jury is still out.

There is no shortage of coroutine and light weight threads, something is still missing though, mainly they require a DIFFERENT language, and if COBOL is still being used, when it should have been dead 30 years ago, this means something...

[legacy]

I am reading this paper
it claims "Threads Cannot be Implemented as a Library": interesting 

[richardman]

I am reading this paper
it claims "Threads Cannot be Implemented as a Library": interesting 

A bit of hyperbole. The problem is the concurrency model of shared (e.g. global) variable access. Not all concurrent programming make use of shared variables the way they imply - may be some, certainly, not all.

A better model for concurrency is probably using channels, which are encouraged by most languages which support concurrency anyway, and not shared memory. However, it's also true that possibly channels cannot be support as library code either.

My own interest in this is back to those "thousands" of IoT sensors and devices communicating. They ought to use a higher level abstraction that poking at the TCP/IP level.

[legacy]

yes, it's good when the model it's shared memory oriented
I agree with you.

[legacy]

It makes me thinking about Ada Protected Object 

an other example: Mutex Object, used by Modula-3

[helius]

Why better models of concurrency are needed:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

[miguelvp]

Erlang is a proven concurrent programming language.

Not hard to get your head around it if you can program FPGAs, also you can only use a variable once, but the message passing is 2nd to none.

[codeboy2k]

Holt was my Professor back in my University of Toronto days... We did ConEuc programming on a 6809 trainer board in our 4th year EE labs.  We built an OS with it during the course.  It was pretty nice to work with, and very cool for the time.  I too still have the original book from the 80's.

By this time, new students were starting to use The Turing Language for general programming, and Turing Plus for systems programming.  Both of these borrowed heavily from ConEuc.  I still like the cleanliness of Turing, although some people look at it like it was some kind of modern day cobol.   I just liked that everything had to be explicitly imported and declared upfront before you used it, and I still like this. I have a love/hate relationship with dynamic programming languages like python, php, lua, etc.

I've never tried Erlang, but it's on my list

[legacy]

what about the RUST language ?