Doubt about funs

[Martin Bjorklund]

"Erik.Johansson" <Erik.Johansson@REDACTED> wrote:

> 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 think that is good.

> 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?

One problem with this is that you would have to come up with a way to
explicitly tell all users of the fun that it's time to refresh.  This
is something you need, since the code might be updated because of bug
fixes or new features, and you definately want to change all
occurences of the old fun in the system.  External calls takes care of
that today.

> And please lobby for a nice semantic for funs and code change.

I agree, it's an important area.

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

I agree with this as well.  The only concern I have with "careful"
design is that it might be difficult to do in real code.  For example,
how can I make sure that the function that defined the fun is not
changed in a future version?  Well, I could define a function with the
only purpose of returning the fun.  Then, how would I make sure that
no funs are added/removed before this one?  I could declare all funs
in a section at the end of the module, and always add funs after the
ones defined, and never remove stale funs.  I'm not sure I like that
approach though.


/martin