Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a

[Andy Wingo]

Hi Mark,

On Sat 14 Jan 2012 21:37, Mark H Weaver <address@hidden> 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/