Mon Jan 23 06:57:16 CET 2012
Sorry I'm a little late with my reply, but the situation is not as simple
as that (at least as of R14B02, I have not re-tested R15): funs can migrate
between versions of a module in some situations.
Here's the thread where I asked a similar question:
Another older thread is referenced in that one and it's also interesting.
On 17 January 2012 04:31, Jon Watte <jwatte@REDACTED> wrote:
> Funs are always bound to the code they are initially loaded from. Only
> name look-ups are affected by code loading AFAICT.
> This has been a source of exceptions in our previous development, because
> the first time you load new code, F is still valid, but the second time you
> load new code, the old code is purged and F is now invalid. Any call to it
> will generate an exception.
> We ended up wrapping our needs for lambdas in a module with state instead.
> Not the most elegant, but allows us to get "dynamic lambdas." If all you
> need in the fun is module:function, you can use a tuple for that instead of
> a fun.
> Americans might object: there is no way we would sacrifice our living
> standards for the benefit of people in the rest of the world. Nevertheless,
> whether we get there willingly or not, we shall soon have lower consumption
> rates, because our present rates are unsustainable.
> On Mon, Jan 16, 2012 at 6:41 AM, Gokul Evuri <chandu.gokul138@REDACTED>wrote:
>> so for instance
>> f() -> 3.
>> x() -> F = fun() -> f() end,
>> A = f(),
>> B = ?MODULE:f(),
>> C = F().
>> right after F hash been defined,
>> a new version of code for f() is defined as follows
>> f()-> threeand loaded.
>> What would be the value of C.
>> *Gokul Reddy Evuri,*
>> *IT Universitet **Göteborg**,*
>> erlang-questions mailing list
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions