If cplx-fun is a macro rather than a function, this doesn't work in arc or anarki at the moment, but I consider this a bug (it's fairly easy to fix, though) - if a symbol evaluating to an object is valid in functional position, the object itself (if it evaluates to itself) should be valid as well.
Of course, what's really needed to solve this problem is hygienic macros. I think, however, that it's probably possible to implement hygienic macros or something close enough in Arc without adding any axioms.
not a bad idea, but it is a limited solution to the problem, since it won't prevent you from creating a new global 'cplx-fun. Plus, it places code dealing with a crosscutting concern right inside the macro. That feels grungy to me.
If I think about the problem my preferred solution would be a function called 'lock-name. Right after defining 'cplx-fun you would call:
(lock-name 'cplx-fun)
Then, whenever this name is redefined, whether locally or globally, it would give a warning when the code is run. There would also be an 'unlock-name function for supressing the warning. This way, you could write macros without worrying about this issue but still had a way to guard against it.
Of course, I might be missing part of the problem or my solution may have its own problems that I don't see right now.
Good luck on your multiprocess library BTW- I think it could be a useful tool. I may look into it sometime soon, if it can be adapted to work with the base arc2.tar.
err, it's not a library, it's a full implementation of Arc.
I'll probably also include some method of locking the global (and only the global) but only with a lot of big warning signs around the locking function, saying that this should be used only if efficiency is a real concern. Also, my intended lock is a true lock: no redefinition of the <edit>global</edit> at all.
Also, ssyntax could potentially help with the apparently long symeval!foo form; say: <>foo maybe?
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.
