# Funs references - clarification needed **URL:** \ **Category:** Questions / Help\ **Tags:** erlang-otp\ **Created:** [October 1, 2022, 11:20am UTC](https://erlangforums.com/t/funs-references-clarification-needed/1887 "2022-10-01T11:20:08Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![kuna.prime](https://erlangforums.com/letter_avatar_proxy/v4/letter/k/b77776/32.png) [@kuna.prime](https://erlangforums.com/u/kuna.prime)\ **Post date:** [October 1, 2022, 11:20am UTC](https://erlangforums.com/t/funs-references-clarification-needed/1887/1 "2022-10-01T11:20:08Z")
If we write in a shell: ```erlang 1> fun() -> "hello" end. #Fun 2> fun() -> "world" end. #Fun 3> ``` we can see that both `funs` have the same printed “reference”. Can someone explain what these numbers after `erl_eval` mean and if we could have different numbers for different `funs`? I think it would be easier to debug and/or understand what is happening if there was some kind of differentiation there. ---
**Author:** ![williamthome](https://erlangforums.com/user_avatar/erlangforums.com/williamthome/32/471_2.png) [@williamthome](https://erlangforums.com/u/williamthome)\ **Post date:** [October 1, 2022, 12:00pm UTC](https://erlangforums.com/t/funs-references-clarification-needed/1887/2 "2022-10-01T12:00:32Z")
Interesting. I had never noticed that the reference is always the same. ---
**Author:** ![mikpe](https://erlangforums.com/letter_avatar_proxy/v4/letter/m/b487fb/32.png) [@mikpe](https://erlangforums.com/u/mikpe)\ **Post date:** [October 1, 2022, 1:47pm UTC](https://erlangforums.com/t/funs-references-clarification-needed/1887/3 "2022-10-01T13:47:22Z")
This is an artifact of you creating code in the shell, which is an interpreter. If you want different printed representation for different same-arity functions then put the code in a module and compile it. The shell uses `erl_eval` to interpret a representation of the code. It doesn’t create new actual (BEAM) code, instead each function expression you enter in the shell gets mapped to a closure combining a pre-existing actual (BEAM) function (that’s the `#Fun`) with free variables that tell it how to interpret calls to it. There is one such BEAM function per arity, which is why those two same-arity funs look the same in your shell. Try looking at those fun values with `erlang:fun_info/1` or `/2`. Look in `lib/stdlib/src/erl_eval.erl` line 339 (OTP-25.1) for details. ---
**Author:** ![rvirding](https://erlangforums.com/user_avatar/erlangforums.com/rvirding/32/178_2.png) [@rvirding](https://erlangforums.com/u/rvirding)\ **Post date:** [October 1, 2022, 2:26pm UTC](https://erlangforums.com/t/funs-references-clarification-needed/1887/4 "2022-10-01T14:26:59Z")
The first field in the fun reference is the name of the module in which the fun is created. In this case they are created by the Erlang evaluator module `erl_eval` which is what you see in the fun reference. The second number is, or at least used to be anyway 😄, the index of the fun in that module, so in this case it was/would have been the 43rd fun. As I said that might not be so now. ---
**Author:** ![kuna.prime](https://erlangforums.com/letter_avatar_proxy/v4/letter/k/b77776/32.png) [@kuna.prime](https://erlangforums.com/u/kuna.prime)\ **Post date:** [October 1, 2022, 7:21pm UTC](https://erlangforums.com/t/funs-references-clarification-needed/1887/5 "2022-10-01T19:21:32Z")
From my testing (at least for now) for `#Fun` - `X` is the module or creation (as others stated before) - `Y` seems to be index in `X` (as stated by @rvirding) and it is an artifact of the shell that is the same in the original example - `Z` seems to have something to do with the module version? `erlang:fun_info/1` shows that Z is marked as `uniq` but I still don’t understand what is it exactly in any case printout of fun doesn’t show much information about an instance of function (how to differentiate between multiple instances?).For module: ```erlang -module(test). -export([rf/0]). rf() -> R = rand:uniform(), fun() -> R end. ``` when we run ```erlang 10> test:rf(). #Fun 11> test:rf(). #Fun ``` both references look the same. IMHO it would be helpful if they were not. ---
**Author:** ![rvirding](https://erlangforums.com/user_avatar/erlangforums.com/rvirding/32/178_2.png) [@rvirding](https://erlangforums.com/u/rvirding)\ **Post date:** [October 1, 2022, 10:39pm UTC](https://erlangforums.com/t/funs-references-clarification-needed/1887/6 "2022-10-01T22:39:00Z")
Well, in one way it is the same fun function, the difference is the environment in each of them which in this case contains the value of the variable `R`, amongst other things. NOTE: what we see here is “just” how the fun is printed. It is not possible to create a fun from its printed representation and of course this printed format could change in the future. The only defined and safe way to get information about a fun is to use the functions `erlang:fun_info/1/2`. ---
**Author:** ![elbrujohalcon](https://erlangforums.com/user_avatar/erlangforums.com/elbrujohalcon/32/241_2.png) [@elbrujohalcon](https://erlangforums.com/u/elbrujohalcon)\ **Post date:** [October 2, 2022, 2:05pm UTC](https://erlangforums.com/t/funs-references-clarification-needed/1887/7 "2022-10-02T14:05:23Z")
I once wrote a blog post exactly about this: [Having fun with funs :). To continue with my Erlang battle-story… | by Brujo Benavides | Erlang Battleground | Medium](https://medium.com/erlang-battleground/having-fun-with-funs-d199a4f522d3) ---
**Author:** ![kuna.prime](https://erlangforums.com/letter_avatar_proxy/v4/letter/k/b77776/32.png) [@kuna.prime](https://erlangforums.com/u/kuna.prime)\ **Post date:** [October 2, 2022, 2:49pm UTC](https://erlangforums.com/t/funs-references-clarification-needed/1887/8 "2022-10-02T14:49:40Z")
Thank you, for sharing the blog post it is really good. For me, it is not surprising at all that there is some “magic” with `erl_eval` when in the shell, rather `uniq` number is mysterious. Furthermore, it is not very intuitive that all instances of anonymous function have the same `uniq`. I get that fun references have markers that firmly identify their “position” in defining the module but I wonder if there is a lost opportunity to have more information there. If my assumption about `uniq` is correct (that it is linked to the version of the module) then we can read reference `#Fun` as: an anonymous function that is defined (Y+1)nth in version Z of module X. Maybe just for clarity reasons, there can be a fourth marker T that would be something as an instantiation number. T doesn’t have to be ordered just guaranteed to be unique. So that we would read `#Fun` as: a T instance of an anonymous function that is defined (Y+1)nth in version Z of module X.