[lisp-hh] Re: [ANN] Erlisp website

[Dirk Gerrits]

"Hoehle, Joerg-Cyril" <Joerg-Cyril.Hoehle at 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