Hi Mark, On Sat 14 Jan 2012 21:37, Mark H Weaver <m...@netris.org> writes:
> If a top-level variable needs to be expanded in user code, then you'd > better explicitly choose a stable name for it. Indeed, this is the best solution, for interface stability. But what should happen when users do introduce top-level variables in their macros, against our recommendations? My point is that the answer cannot be, "generate a truly random identifier". Simply advising users not to introduce bindings is not a great answer. > In the general case, where a macro may have been considerably reworked > from one version to the next, it's _impossible_, even in principle, > for the system to reliably decide the correspondence between top-level > gensyms in the new code vs the old code. Even your method is only a > heuristic that will often do the wrong thing, in both directions: it > will cause unintended name collisions in R5RS standard code, and it > will also sometimes change the name of a top-level when you didn't > want it to. Of course. It's a heuristic. We document the heuristic and move on, no? If users really find themselves caring about this, they will have to learn the heuristic. > There's another option: we could properly track the compile-time > dependencies of each module, and automatically consider a .go file stale > if _any_ of its compile-time dependencies are newer than it. We do need to do this, yes. This would be a great thing to add, once we switch to ELF as our format of compiled files. (You would add a section for this.) > Furthermore, we could provide distros with the necessary infrastructure > to automatically recompile guile modules as needed after package > upgrades. That is orthogonal to this question. Recompilation can be triggered on package dependencies, instead of embedded expansion dependencies. That's what I was planning on doing for the guildhall, for example. Regards, Andy -- http://wingolog.org/
