Funs behaving differently after native compilation

[Richard Carlsson]

Joel Reymont wrote:
> I could certainly change things to
>
>     Closer = fun(Sock) -> gen_udp:close(Sock) end,
>     monitor(self(), Sock, Closer),
>
> for this particular case but I'm also passing the name of the module
> from the command like to invoke the script function in it.
>
> I don't see how I can construct a real fun from an atom that is the
> module name.

You could do something like this:

   foo({M,F}) ->
     Closer = fun(Sock) -> M:F(Sock) end,
     monitor(self(), Sock, Closer)

or if only the module name is changing:

   foo(M) ->
     Closer = fun(Sock) -> M:close(Sock) end,
     monitor(self(), Sock, Closer)

etc.

The OTP guys recently added dynamic-lookup "funs" on the form
'fun foo:bar/2', but it seems that you cannot create them using
variables, as in "fun M:F/A" (which would be handy in my opinion).
Perhaps this can be added? The advantage over tuples is that
is_function/1 yields true for the funs, and that there is no
confusion about the arity of the called function. (E.g., if
you use {M,F}, and then change the number of arguments, but
forget to update some call site, it might continue to "work"
by calling the wrong function. Not good.) Also, analyses like
those done by Dialyzer are more easily foiled by passing around
atoms - or (shudder!), even manipulating strings and converting
them to atoms and finally using those atoms to call a function!

	/Richard