I want to use the information contained in $foo in the module. I know, I could pass $foo as an argument, but I have a lot of functions in my module and I would like to avoid this redundant information.

IMHO, it will be better to keep the module independent and "modular". If every script that uses the module needs to declare the specific variable name $foo so that the module can use that variable, this strikes me as a somewhat unusual demand to place on the caller.

Given that main has a value that is needed throughout the module, it would be best for the module to have its own internal variable for holding this value, and to provide a method for the caller to initialize the value just once before using other methods in the module.

If the value changes dynamically over the run-time of the caller script, you could consider having the caller pass a scalar reference when initializing the module. This way, either the call or the module can update it as needed, and the other can access the updated value without further ado.

OTOH, issues of that sort might be hints that something has gotten missed or messed up in the module design. What you're talking about in your question is a matter of creating a global variable to be shared by the caller and the module. But globals sort of like the antithesis of modules.

Maybe you don't intend to use your module with any other script -- you're just calling it a "module" for lack of a better term (it's in a different file, it's not "main", etc). But modular independence is desirable for maintainability, as well as portability and re-use.

I'm sorry this wasn't the short answer you wanted; adding and using an initializer method in your module will require a few lines more of code, relative to getting the syntax right for accessing a main variable from within a module. But you might find that it feels better in the long run.