How does compiler and other stuff works in closures

New to Julia
4

I think you’re mixing a lot of things up, which is understandable because programming terminology is extremely vague and contextual. So I’ll explain it in terms typical for Julia users, and you need to understand that it can be different in other languages.

  • The only namespace in the core Julia language is a module, and the names it holds are global variables. A module is also a global scope. Local scopes are not called namespaces, so if you want to distinguish global from local scopes, say scope.
  • Scopes only contain names, also known as variables, not the objects the variables are assigned. We may refer to an object via an assigned variable, like the “outer1 function in the global scope,” but that strictly means outer1 is in the global scope and is assigned a function. This by the way is how Python works too; these are not languages where variables can be synonymous with owned objects.
  • Where a function object, its methods, and compiled method code are stored is an implementation detail, not part of the language specification. Nested functions and closures don’t literally store functions inside another function, the placement is only about what variables their scopes can access. In the current implementation, the written definitions of the outer1 and inner1 methods added separate entries to one global method table, before any calls. The outer1 function is assigned to the global const variable outer1, and inner1 functions are instantiated by outer1 calls, where the definitions are. If it sounds strange that inner1 methods existed before its functions do, it should be known that the functions’ type was also made at definition and assigned a hidden global const variable, you can check Base.return_types(outer1) before any calls.
  • The compiler does not approach globally defined methods and closures’ methods differently, though closures can access local variables that can be uninferrable in their own ways. There’s no point in making closures to optimize compilation, and it is completely unrelated to the Performance Tips section you linked about compiling for too many concrete and likely parametric types.

I have no idea where these ideas come from or what they could mean, I think you should just ignore it.

2 Likes