Doubt about funs

[Ulf Wiger]

On Wed, 21 Feb 2001, Martin Bjorklund wrote:

>"Erik Johansson" <happi@REDACTED> wrote:
>
>> But there is no reason to do so either. If the code defining the fun is
>> changed then the code that applies the fun should get a new fun.
>
>How do you propose this should be done in practise?  You'd have to
>make sure that all processes (ets tables, files, ...) which holds a
>function gets notified when the new code is loaded.  This is simply
>not feasible.

Since funs are actually made into real functions by the compiler, they
seem to have roughly the same properties as ordinary functions during
code change. I've run some tests, and it does seem to be the case that
as long as the fun is tail recursive (doesn't wait for a return
value), then upgrading doesn't break the fun as long as the arity
stays the same. This is the same as for ordinary functions.

It then becomes an issue of interface management.

In general, changing interfaces in an incompatible manner during
system upgrade is asking for trouble -- especially if it's a callback
function which is relatively frequently used. It doesn't really matter
if it's a fun or a variable like Module or {Module, Function};
you still have to suspend all processes referencing the function and
upgrade all of them at the same time.

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.

Still, I would like to see a uniform method of specifying what _is_
actually part of an interface, in a way that you can easily spot what
has changed. It would be nice if this method allowed for automated
analysis.

We (AXD 301) try to collect interface functions in a separate
interface module. This doesn't cover exported records and funs,
however. Regarding records, the .hrl file must be published in a
special library subdirectory, and users of the .hrl are not allowed to
include it directly from the application's inc/ directory. Thus, we
can see what compile-time dependencies are exported from an
application. This is non-OTP-standard, though (there doesn't seem to
be an OTP standard that addresses the issue.)

/Uffe
-- 
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB