Doubt about funs

[Erik.Johansson]

 "Martin Bjorklund" <mbj@REDACTED> wrote:
> 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.
Well external calls take care of that to a certain degree today, you might still need to explicitly handle changes to interfaces and to data representation.

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

What I meant with "careful design" was not to try to write funs that don't change but to design servers so that they explicitly can upgrade to a new fun when the code changes. You say that this is infeasible or difficult in real code but if you are aware of the problem from the outset I don't think it is harder than, for example, the problem of handling changes in the representation of data after code change. (I'm not saying that this is an easy problem. ;) Using a {M., F} instead of a fun don't solve the real problems with code change it just hides some of the deeper problems behind the simplicity of the remote call. 

 /Erik