Doubt about funs

[Erik.Johansson]

Paulo Ferreira  wrote:
> So, here is another advantage of erlang: One doubt and in two hours time
> I have five correct answers !!!
And then the obligatory debate starts ;)

Ulf Wiger wrote: (cited out of context)
> I will admit that my fear of funs in this context is based on 
> previous experiences. Most of the past problems appear to have been
> fixed.

>It then becomes an issue of interface management.

Yes, this is my point; you can use a fun just as well as {M, F} but you would have to design things a bit differently from the beginning.
 
My real concern is what the semantics for funs during code change should be. In the current system processes holding on to funs that changes twice get killed. Some say this is good because then you can be sure that old code is phased out.  I would like to try a different behavior where existing funs holds on to the code as long as needed in stead. This could lead to an ever increasing amount of code if one is not careful, but isn't that better than having processes crash if you are not careful?
 
Martin Björklund wrote:
> erik> What you describe will happen in the current implementation if
> erik> the function defining F is changed (or any funs are added or
> erik> removed before the fun defining F). 
>
> So, it's still a problem.  If this problem was solved, so that it
> worked as you described above, I'd be the first to start using funs
> for everything!
 
Yes it is still a problem, but if you know about it and are careful with how you use funs, you can use them for everything. 
And please lobby for a nice semantic for funs and code change.
 To summarize my view:
 1. For short lived tasks: always use a fun.
 2. For spawing use a tail-recursive fun.
 3. For long-lived (call-backs) either make a careful design or stick to {M., F} if you feel that it is easier.

/Erik