Such use of a "b" function would collide with two many unrelated uses of a local variable or parameter named "b".
Note that even if you can declare constants, in a relevant context where ther's no collision with a function "b" (so that the function won't be called many times, functions are still not declarable as "pure" in Lua, meaning that their evaluation wit the same parameter values will always return the same value (without side effect from their environment), and so that such functions calls can be cached (in implicitly declared local temp variables), or refactored by the Lua compiler (e.g. moved out of a loop).
We should be able to declare a function as being pure, but the Lua compiler could also determine it itself, if it sees that the function code does not depend on its calling environment (note that any subcall to an external library or to other functions in the same context would make it impure, unless the subcalled functions themselves are pure.
If the compiler determines some code that is "purely functional", it can easily refactor it, including with dead code elimination, or preevaluation of common subexpressions at compile time without any performance cost at run-time (it would be useful when there are debugging configuration using constants in a header, that can be easily modified in the source, or when those constants come from an environment that the function itself cannot alter: Lua would itself behave at compiler time like a preprocessor... but at the price of a possibly longer compilation time; the compiler would intrindicaly generate local temporary variables).
Local temporary variables could then only be initialized once, possibly lazily if they are fist initialized to an internal tracking reference to a hidden object (whose first dereference would execute the bound function call to compute its value, and then never written again; and that variable could be persistant for simple value types, or weakly persistant for complex value types like object references: the garbage collector may eventually dispose it and reset it to the initial tracking object that would force the _expression_ to be computed again to rebuild that object).
