Suggested Example/ emacs questions

[Jim Larson]

In message <39E2FB52.CB8FE6E9@REDACTED> Tony Rogvall writes:
>Me and pekka designed a multithreaded implementation of erlang
>~ two years ago (put on ice).

I'd sure like to see it dusted off.  When selling Erlang as an
alternative to C's pthreads, it's a little embarassing to mention
that there's no speedup on multiprocessor machines.  Running several
emulators on one machine doesn't seem adequate when the langauge
semantics should allow a multiprocessor implementation with no
impact on the application code.


>Then we remodel the message passing and signal sending so that
>a message was a sort of a signal. i.e. everything was signals. It was then
>up to the receiving process (internally) to sort things out.
>
>One thing that I thought about then (or was it pekka) was to implement a
>per process signal handler, similar to the error handler. Then this
>sorting out messages from signals / exit propagation / code reloading /
>suspend / resume could be implemented in erlang in a signal handler.
>
>What do you think about that one ???

One of the things that impresses me about Erlang is that the
inevitable tensions between purity, simplicity, and elegance on
the one hand, and the immediate needs of large-scale, commercial
products on the other, have always been met in a practical compromise.
I think that Erlang needs to be as wary of "Creeping Elegance" as
of "Creeping Features".

For instance, built-in support for ETS tables seems to be the Right
Thing.  Henry Baker's essay

	http://ftp.netcom.com/pub/hb/hbaker/TreeShadow.html

(the link may not work - Netcom's site seems to have gone away -
anyone know where it's gone to these days?) makes the interesting
point that large-scale digital hardware designs aren't purely
functional - they are structured as stateful registers with functional
logic as glue between them.  Erlang's tables, modules, and messages
fill the same role.

I've always had mixed feelings about the loss of vanilla Erlang
message-passing in an OTP environment.  However, I've still gotten
most of my work done with generic behaviours.  The signals proposal
above seems isomorphic to mapping everything onto Erlang messages,
but creating a system-level receive loop.  I'd like to see ideas
about generalizing this mechanism so that application programmers
could use it.  However, I'll also guess that going down that path
will lead to "Creeping Elegance".

Ambivalently Yours,

Jim