Hi Mark, Good to hear from you!
On Thu 30 Jun 2011 19:35, Mark H Weaver <[email protected]> writes: > Andy Wingo <[email protected]> writes: >> Well why not have the name of "t" be "t" plus some string which depends >> only on the incoming form -- like its hash value. (Or the outgoing >> form; the considerations are different but similar.) > > This won't work. Two identical invocations of the same macro must > generate distinct toplevel variables There are important cases when the opposite is true. Consider a GNU/Linux distribution, which provides binary packages for Guile and for Guile-Foo. Both distribute compiled Guile files -- currently .go files, perhaps ELF .so files in the future. Let's say that Guile-Foo uses a record type from Guile, so that it residualizes a reference to a generaated temporary from Guile. Cool. Now I download the source package for Guile from the distro. I want to make an unrelated change to Guile, in the spirit of the LGPL, compile a binary Guile package, and try it with the new Guile-Foo. But here's the kicker: compiling the define-record form from Guile *must* be able to produce the same "name" for the generated temporary. > One possibility is to include the source code location in addition to > (or instead of) the form. I am skeptical of this. In my example above, let's say that I'm using a record type from (rnrs exceptions). Let's say that my change involves some procedure in module/rnrs/exceptions.scm, but before the define-record invocation, and that it results in the define-record being on a different line. Having my change cause a different temporary to be generated would be quite surprising. Cheers, Andy -- http://wingolog.org/
