[erlang-questions] Was Re: Bug ?! now Erlang comment (LONG LONG)

[Robert Virding]

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 
all users.

Robert

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.
> 
> BR,
> Ulf W