Arc Forumnew | comments | leaders | submitlogin
2 points by drcode 5744 days ago | link | parent

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.

2 points by almkglor 5744 days ago | link

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?