Dirk,
I wish you good luck. I recommend you to read Matthew Fuchs' PhD (1995) about Dreme. It's Erlang concepts taken to an implementation of Scheme.
I'd appreciate a Common Lisp with real language-level concurrency (parallelism?), like in Erlang. The Dreme paper once made be believe a threading Oaklisp with a software write barrier as the basis for a generational GC would be doable on the Amiga (no time to figure it out :) -- Oaklisp also is a byte-code machine. The key was that each thread would have its own 1st generation memory pool, so allocation would be very fast, and copying to the shared heap would only occur when needed, i.e. for message passing. In my simple model, the GC would need to stop all threads (or rather wait until each reaches a safe point, e.g. doing I/O or consing).
Each time I suggested adding Coroutines to CLISP, the proposal was turned down because "threads are the real thing". Gilbert Baumann once had coroutines in his copy of CLISP in 1998, but that was never integrated and I fear it's lost. IMHO, threads are not the real thing, because - they cost too much (resources for stack, context switch) - they introduce need for synchronization, where there was no need before.
Erlang and Oz schow, among others, that it's possible to express some problems very elegantly using seemingly parallel constructs, but without the need for actual threads.
easier to use and less "low-level" than this industry best practice.
IMHO, an approach similar to Erlang's, or also using constrained variables like in the Oz language could be a key to fun/beautiful/readable/verifyable concurrency, as opposed to the thread-stuck, thread-savy and thread-heavy industrial practice.
I call the "Smalltalk lie" because it talks about message passing whereas all it's doing is synchronous (blocking) method calls, with all the known problems. Erlang does real message passing in my words, because the senders and receivers are autonomous.
Although I have followed the evolution of Erlang for several years, I sadly haven't used it in a project. I tend to stick to single-threaded applications using CLISP, Kawa (Scheme in a JVM), or use Python's coroutines here and there, longing for a better world.
[BTW, isn't there a better place for this than 3 mailing lists?]
Regards, Jörg Höhle.
"Hoehle, Joerg-Cyril" Joerg-Cyril.Hoehle@t-systems.com writes:
I wish you good luck.
Thanks Jörg.
I recommend you to read Matthew Fuchs' PhD (1995) about Dreme. It's Erlang concepts taken to an implementation of Scheme.
This one, yes? http://citeseer.ist.psu.edu/fuchs96dreme.html Thanks for the reference. It looks very interesting.
I'd appreciate a Common Lisp with real language-level concurrency (parallelism?), like in Erlang.
Working on it. ;)
The Dreme paper once made be believe a threading Oaklisp with a software write barrier as the basis for a generational GC would be doable on the Amiga (no time to figure it out :) -- Oaklisp also is a byte-code machine. The key was that each thread would have its own 1st generation memory pool, so allocation would be very fast, and copying to the shared heap would only occur when needed, i.e. for message passing. In my simple model, the GC would need to stop all threads (or rather wait until each reaches a safe point, e.g. doing I/O or consing).
Sounds interesting. I believe Erlang implementations have moved to a single heap, but Erlang has immutable data. In any case, I don't have any control over these matters until I start hacking on a Lisp's internals, which I'd like to postpone as much as possible, maybe indefinately.
Each time I suggested adding Coroutines to CLISP, the proposal was turned down because "threads are the real thing".
Sorry to hear that.
Erlang and Oz schow, among others, that it's possible to express some problems very elegantly using seemingly parallel constructs, but without the need for actual threads.
Yes, I'm beginning to see that. I've never had a really anti-coroutine view in the first place, but I'm now starting to see that although you need preemption sometimes, you very often don't.
IMHO, an approach similar to Erlang's, or also using constrained variables like in the Oz language could be a key to fun/beautiful/readable/verifyable concurrency, as opposed to the thread-stuck, thread-savy and thread-heavy industrial practice.
I've only just started reading the Oz book (Concepts, Techniques, and Models of Computer Programming), and I don't know what constrained variables are. Does it have to do with constraint solving?
I'm definately going to look at concurrency aproaches like Oz's, but I'm going to focus on Erlang's model first. See phase 1 / phase 2 of my Erlisp roadmap (http://www.dirkgerrits.com/erlisp/roadmap.html). One of the reasons I chose Erlang, is because I believe their model is indeed fun, beautiful, and readable, it has already proven its worth, and Erlang is not extremely far from being a Lisp.
I call the "Smalltalk lie" because it talks about message passing whereas all it's doing is synchronous (blocking) method calls, with all the known problems. Erlang does real message passing in my words, because the senders and receivers are autonomous.
So true. My main problem with Smalltalk (and most "OOP" languages) is that it doesn't have generic functions though. They might just be the best thing since sliced bread. :)
... use Python's coroutines here and there, longing for a better world.
Stackless Python's coroutines, right? I actually came to Lisp through the C++ -> Python -> Scheme -> Common Lisp route, and although I looked at continuations in Stackless Python, I never understood them until I knew Scheme, at which point I didn't want to do much with Python anymore. ;)
[BTW, isn't there a better place for this than 3 mailing lists?]
Hopefully, we'll be able to do it all on a single European mailing list very soon. Alternatively, we could forego mailing lists and move to my thread on comp.lang.lisp.
Kind regards,
Dirk Gerrits
-
Dirk Gerrits -
Hoehle, Joerg-Cyril