bug#15602: Compiling several files in the same session [2.0.9]

[ludo@gnu.org (Ludovic Courtès)]

Consider these three modules:

--8<---------------cut here---------------start------------->8---
(define-module (one)
  #:use-module (srfi srfi-9)
  #:export (run-time
            expansion-time))

(define run-time 'one)
(define-syntax expansion-time
  (identifier-syntax 'one))
--8<---------------cut here---------------end--------------->8---

two.scm:

--8<---------------cut here---------------start------------->8---
(define-module (two)
  #:use-module (one)
  #:export (bar))

(define bar
  (list run-time))
--8<---------------cut here---------------end--------------->8---

and three.scm:

--8<---------------cut here---------------start------------->8---
(define-module (three)
  #:use-module (two))

(define chbouib
  bar)
--8<---------------cut here---------------end--------------->8---

And now see how the order influences the compilation result:

--8<---------------cut here---------------start------------->8---
$ guile --no-auto-compile -L . -c '(use-modules (system base compile)) (for-each compile-file (list "one.scm" "two.scm" "three.scm"))'

$ guile --no-auto-compile -L . -c '(use-modules (system base compile)) (for-each compile-file (list "three.scm" "two.scm" "one.scm"))'

$ guile --no-auto-compile -L . -c '(use-modules (system base compile)) (for-each compile-file (list "one.scm" "three.scm" "two.scm"))'
Backtrace:
In system/base/compile.scm:
 153: 19 [#<procedure 1985040 at system/base/compile.scm:151:8 (port)> #<closed: file 0>]
 216: 18 [read-and-compile #<input: three.scm 5> #:from ...]
 232: 17 [lp () #f #<module (#{ g180}#) 189aa20>]
 180: 16 [lp (#<procedure compile-tree-il (x e opts)>) (define-module # # ...) ...]
In ice-9/boot-9.scm:
2325: 15 [save-module-excursion #<procedure 19a84e0 at language/scheme/compile-tree-il.scm:29:3 ()>]
In language/scheme/compile-tree-il.scm:
  31: 14 [#<procedure 19a84e0 at language/scheme/compile-tree-il.scm:29:3 ()>]
In ice-9/psyntax.scm:
1091: 13 [expand-top-sequence ((define-module (three) #:use-module ...)) () ...]
 976: 12 [scan ((define-module (three) #:use-module ...)) () ...]
 270: 11 [scan ((#(syntax-object let # ...) (#) (# #) ...)) () ...]
In ice-9/eval.scm:
 411: 10 [eval # ()]
In ice-9/boot-9.scm:
2875: 9 [define-module* (three) #:filename ...]
2850: 8 [resolve-imports (((two)))]
2788: 7 [resolve-interface (two) #:select ...]
2713: 6 [#<procedure 15381e0 at ice-9/boot-9.scm:2701:4 (name #:optional autoload version #:key ensure)> # ...]
2986: 5 [try-module-autoload (two) #f]
2325: 4 [save-module-excursion #<procedure 17a3360 at ice-9/boot-9.scm:2987:17 ()>]
3006: 3 [#<procedure 17a3360 at ice-9/boot-9.scm:2987:17 ()>]
In unknown file:
   ?: 2 [primitive-load-path "two" ...]
In two.scm:
   1: 1 [#<procedure 1714940 ()>]
In ice-9/boot-9.scm:
 106: 0 [#<procedure 19b0f80 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]

ice-9/boot-9.scm:106:20: In procedure #<procedure 19b0f80 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
ice-9/boot-9.scm:106:20: In procedure #<procedure 1714940 ()>: Unbound variable: run-time
--8<---------------cut here---------------end--------------->8---

So, what happened?

In the last case (one, three, two), the compiler:

  1. compiles ‘one.scm’, which creates module (one) in the global name
     space with just ‘expansion-time’ in its exported bindings;

  2. when compiling ‘three.scm’, it loads ‘two.scm’; since (two) uses
     (one), it does ‘(resolve-module '(one))’, and since (one) already
     exists it is used;

     however, the (one) we have comes from step 1, and lacks the
     ‘run-time’ binding, hence the unbound variable failure.

I think the right thing would be to use a separate module hierarchy in
the dynamic extent of ‘compile-file’, somehow, such that all module side
effects are isolated.

Of course the above can be worked around by running ‘compile-file’ in a
child process, but forking alone is more expensive than ‘compile-file’,
so that’s not really a solution when there are many files.

Thanks,
Ludo’.