It seems like a module system could mitigate this problem. In other languages, functions resolve variables by first looking in their local scope and then by checking to see if the variable is global to the module/package in which it was defined.
I guess this is harder for macros, since they simply alter your code in-place and after the macro is executed, you have no way of knowing where the code came from. However, if we did have a module system, then you could refer to cplx->cplx-fun or whatever the module notation would be and thus the problem wouldn't occur.
Of course, this would require saying cplx-> or something like that in front of all of you calls to internal module functions/macros, which would be about as cumbersome as the proposed solution.
Perhaps we could have a type of macro which adds these module-specifying prefixes to your function calls when the macro is expanded. Of course, without knowing how the module system would even work, it's hard to gauge whether this would ultimately make things better or worse.
Depends on how the module system is constructed. If modules are first class objects and not a set of symbols like CL packages are, then the module name itself may be shadowed by a local, i.e. 'cplx itself could fall victim.
> Perhaps we could have a type of macro which adds these module-specifying prefixes to your function calls when the macro is expanded
CL packages solve this problem fine. I was hoping Arc wouldn't have to go down that route (because it always confuses newbies and adds a lot of complexity) but the more problems arise, the more I appreciate how good packages are.
