[erlang-questions] Was Re: Bug ?! now Erlang comment (LONG LONG)
Sun Oct 22 23:20:36 CEST 2006
Ulf, I was a little unclear about what I was complaining with link. It
was not the monitoring in itself, which does have its place.
With links there are 3 parameters which describe the link:
signal/message, single/multiple and uni-/bidirectional. With link/1 you
get a signal-single-bidirectional connection berween the processes and
with monitor/1 you get a message-multiple-unidirectional connection. You
could of course have any combination of these parameters that you need.
My main complaint is that instead of generalising the basic link
construct - connecting two processes to exchange termination information
- it is defined as something different. So instead of ONE versatile
basic construction you now have TWO restricted ones neither solving the
whole problem. Basically it is just a hack added to solve a specific
problem with no real thought given to its place in the whole, just
another special case.
I know: this is only ONE thing so why worry? But I think too much has
been added to solve specific problems without thinking about the
language as whole. There has been no holistic view to Erlang just adding
fixes as they arise. In the end you get a mess.
I think sometimes you should refuse adding stuff which might solve one
user's problem but is not good for the system as a whole, which affects
P.S. If I wanted to be really picky I could also say that the name
monitor is a misnomer as it is really not monitoring the process, just
detecting its termination. A REAL monitor would tell much more of what
is going on.
And things should have a name which reflects what they do.
Ulf Wiger (TN/EAB) wrote:
> Of course, the changes you speak of were made in order to address real
> shortcomings in the original solution (even though it may have been
> regular and elegant). One major problem with link was that it was
> two-way (and therefore didn't work well as a monitor), and had
> process-global scope (i.e. you couldn't safely do
> link-request-await_reply-unlink, since some other function (or the other
> process) might call unlink and quietly remove the link.)
> The symmetry of exit messages probably would have worked if erlang had
> really been a pure message passing environment, perhaps more in line
> with Morrison's flow-based programming, but given that it leaned quite
> heavily towards sequential programming as well, regular exceptions with
> stack traces were really necessary.
> Ulf W
More information about the erlang-questions