GNU bug report logs - #16314
Macro dependency tracking issue in guile auto compiler

Previous Next

To reply to this bug, email your comments to 16314 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Panicz Maciej Godek <godek.maciek <at> gmail.com>
To: bug-guile <at> gnu.org
Subject: Macro dependency tracking issue in guile auto compiler
Date: Wed, 1 Jan 2014 14:19:53 +0100

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.

Message #8 received at 16314 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Panicz Maciej Godek <godek.maciek <at> gmail.com>
Cc: 16314 <at> debbugs.gnu.org, request <at> debbugs.gnu.org
Subject: Re: bug#16314: Macro dependency tracking issue in guile auto compiler
Date: Wed, 15 Jan 2014 15:18:34 -0500

severity 16314 wishlist
thanks

Panicz Maciej Godek <godek.maciek <at> gmail.com> writes:
> 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.

Yes, this is a known issue.  I agree that it would be nice to improve
this -- perhaps in 2.2 -- but I'm also worried that it might lead to
absurd amounts of needless recompiling, because one often makes minor
changes to modules that export macros, without the macros being changed
at all.

I'm marking this as a "wishlist" item.

     Thanks,
       Mark

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.