# Why the free variables in function body don't get bound at function definition time?

**URL:** <https://discourse.julialang.org/t/why-the-free-variables-in-function-body-dont-get-bound-at-function-definition-time/128860>\
**Category:** New to Julia\
**Tags:** offtopic, design\
**Created:** [May 9, 2025, 3:29am UTC](https://discourse.julialang.org/t/why-the-free-variables-in-function-body-dont-get-bound-at-function-definition-time/128860 "2025-05-09T03:29:11Z")\
**Posts on this page:** 1\
**Showing post:** 23

<div class="post-metadata">

**Author:** ![bertschi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bertschi/32/33462_2.png) [@bertschi](https://discourse.julialang.org/u/bertschi)\
**Post date:** [May 10, 2025, 7:11am UTC](https://discourse.julialang.org/t/why-the-free-variables-in-function-body-dont-get-bound-at-function-definition-time/128860/23 "2025-05-10T07:11:34Z")

</div>

> [@Leon\_Niceday](#):
>
> The way this would work is by having the following rule: if, at the time of function definition, the free variable that needs to be accessed is itself under construction/definition (like what happens to `obj` above), then the resolution of that free variable if left to the call time.

Ok, let’s step back a bit … making these rules dependent on global context – whether a variable exists already or not – sounds like a recipe for confusion.  
Here are some arguments, why I think it might not be a good idea in the first place:

1. Usually functions are bound globally and (as you acknowledge) your rule would apply to functions too. This would be very annoying for interactive work, i.e., define g, define f using g, test f and see its wrong (problem was in g already), fix g, try f again (success).  
Note that with your rule, the old definition of g would still stick around and f would need to be redefined as well to see the change – as you can imagine this gets messy very quickly with any kind of interactive workflow. If you ever worked with Python it is annoying enough that old objects stick around when you redefine a class and languages designed for interactive use, e.g., Smalltalk, Common Lisp, can even handle this case gracefully.  
Some compiled languages could get away with this, e.g., Haskell which only allows a single global definition anyways.

2. Your rule would also not solve the fundamental problem of “spooky action at a distance” due to global variables but simply shift the problem:

3. Finally, it would fundamentally change the semantic of functions which don’t evaluate their body until called (part of it would be evaluated by your rule already at definition time). You’re right that closures do keep a reference to their defining environment, but this was actually introduced to restore local reasoning for higher-order functions:

---

_[View the full topic](https://discourse.julialang.org/t/why-the-free-variables-in-function-body-dont-get-bound-at-function-definition-time/128860)._