From: Panicz Maciej Godek <godek.maciek@gmail.com>
To: 16314@debbugs.gnu.org
Subject: bug#16314: Macro dependency tracking issue in guile auto compiler
Date: Wed, 1 Jan 2014 14:19:53 +0100 [thread overview]
Message-ID: <CAMFYt2af172w+ORdO-2Piccy_fzhqreanrVdpqVYP2UhmPLw2g@mail.gmail.com> (raw)
Hi,
I've noticed that if macros are ever used in the process
of auto-compilation, the dependency is forgotten, so
even if a module that contains the definition of a macro
gets recompiled, the module that uses the macro remains
unchanged.
For example, consider the following situation. I have
two modules and a program that uses one of them.
The directory tree looks like this:
.
|-- module
| |-- master.scm
| `-- slave.scm
`-- program.scm
The module/master.scm contains the following code:
--8<---------------cut here---------------start------------->8---
(define-module (module master)
#:export (macro function))
(define-syntax-rule (macro)
(display "macro expanded"))
(define (function)
(display "function called"))
--8<---------------cut here---------------end--------------->8---
The module/slave.scm uses the master module:
--8<---------------cut here---------------start------------->8---
(define-module (module slave)
#:use-module (module master)
#:export (f))
(define (f)
(macro))
--8<---------------cut here---------------end--------------->8---
But the program.scm uses only the slave module:
--8<---------------cut here---------------start------------->8---
(use-modules (module slave))
(f)
--8<---------------cut here---------------end--------------->8---
If I run the program, I get the following result:
user cwd $ GUILE_LOAD_PATH=. guile -s program.scm
;;; <auto-compilation of program.scm>
;;; <auto-compilation of module/slave.scm>
;;; <auto-compilation of module/master.scm>
macro expandeduser cwd $
Oops, I forgot to add a trailing newline. But that's no problem!
I edit the body of module/master.scm:
- (display "macro expanded"))
+ (display "macro expanded!\n"))
and then run the program once again:
user cwd $ GUILE_LOAD_PATH=. guile -s program.scm
;;; <auto-compilation of module/master.scm>
macro expandeduser cwd $
Damn! That didn't work. See the problem? If I modify
a module that exports any syntax definition, it should
force all the modules that use it be recompiled -- otherwise
the auto-compilation feature is only a potential source
of confusion, and forcing recompilation of all user modules
if at least one of them has been modified seems to be
a less confusing default strategy, if a more fine-grained
dependency tracking is too difficult to implement.
I've tested that behaviour under guile 2.0.5, guile-2.0.9,
guile-2.0.9.98-36c40 from hydra and guile-2.1.0.545-61989
from git, and everywhere it worked the same.
Regards,
M.
next reply other threads:[~2014-01-01 13:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-01 13:19 Panicz Maciej Godek [this message]
2014-01-15 20:18 ` bug#16314: Macro dependency tracking issue in guile auto compiler Mark H Weaver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMFYt2af172w+ORdO-2Piccy_fzhqreanrVdpqVYP2UhmPLw2g@mail.gmail.com \
--to=godek.maciek@gmail.com \
--cc=16314@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).