bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: `set!' of generated temporary in macro expansion causes warning


From: Andy Wingo
Subject: Re: `set!' of generated temporary in macro expansion causes warning
Date: Thu, 30 Jun 2011 20:12:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Hi Mark,

Good to hear from you!

On Thu 30 Jun 2011 19:35, Mark H Weaver <address@hidden> writes:

> Andy Wingo <address@hidden> 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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]