Modules with Circular Dependencies

Modules with Circular Dependencies

[Noah Lavine]

Hello all,

I recently ran up against an issue about modules with circular
dependencies while working on PEG stuff. I reduced it to the following
test case.

Here is file "test-a.scm":

(define-module (test-a)
  #:use-module (test-b))

(define-syntax hello
  (syntax-rules ()
    ((hello) "Hello, world!\n")))

And here is "test-b.scm":

(define-module (test-b)
  #:use-module (test-a))

(display (hello))

As you can see, test-a and test-b have a circular dependency in which
test-a defines syntax that test-b uses.

If I run "guile -L "." -s test-a.scm", I get the error

;;; WARNING: compilation of /Users/noah/Desktop/guile/guile/test-a.scm failed:
;;; key unbound-variable, throw_args ("module-lookup" "Unbound
variable: ~S" (hello) #f)

Clearly the order of compilation is a problem. So I tried this
modified test-a.scm:

(define-module (test-a))

(define-syntax hello
  (syntax-rules ()
    ((hello) "Hello, world!\n")))

(use-modules (test-b))

I moved the reference to test-b to the end, but got the same error.

So clearly the module system doesn't like circular dependencies on
syntax. I think it probably should understand them. I have a feeling
that they don't end up adding complexity to compilation, even though
it seems like they would, because in order to compile a module you
have to search its dependencies for syntax definitions anyway.
However, either way, I don't think this issue is documented in the
manual.

So what do you all think should happen in this case?

Noah

Re: Modules with Circular Dependencies

[Ludovic Courtès]

Hello!

The problem is that modules are resolved at compile-time, in addition to
run-time, so there just can’t be circular dependencies.

Besides, I think it’s generally a problem from an engineering viewpoint
when cycles are introduced.

So my feeling is that Guile should be able to detect cycles and warn
users.

Thanks,
Ludo’.

Re: Modules with Circular Dependencies

[Noah Lavine]

Hello,

> The problem is that modules are resolved at compile-time, in addition to
> run-time, so there just can’t be circular dependencies.

It's true that a module couldn't depend, at compile-time, on a module
that was only available at run-time. However, I think we could handle
circular dependencies as long as all of the modules involved were
available at compile-time. I would even say that this is one more
instance of the general principle that people shouldn't have to do
things that computers are able to do for them - in this case, you
shouldn't have to manually order your syntax definitions and uses when
your computer can do a graph search for you.

> Besides, I think it’s generally a problem from an engineering viewpoint
> when cycles are introduced.

This sounds like it could be true, but it's so general I don't know
how to respond. Could you talk more about it, or give an example?

> So my feeling is that Guile should be able to detect cycles and warn
> users.

Yes, at a minimum cycle detection would be good.

Noah

Re: Modules with Circular Dependencies

[Andy Wingo]

On Fri 18 Mar 2011 22:16, Noah Lavine <noah.b.lavine@gmail.com> writes:

>> The problem is that modules are resolved at compile-time, in addition to
>> run-time, so there just can’t be circular dependencies.
>
> It's true that a module couldn't depend, at compile-time, on a module
> that was only available at run-time. However, I think we could handle
> circular dependencies as long as all of the modules involved were
> available at compile-time. I would even say that this is one more
> instance of the general principle that people shouldn't have to do
> things that computers are able to do for them - in this case, you
> shouldn't have to manually order your syntax definitions and uses when
> your computer can do a graph search for you.

While I'm sympathetic to the sentiment here, the case you present (and
the PEG case; about which more tomorrow) is as Ludovic described it:
modules depending on each other at compile-time.  `define-module' and
`use-modules' resolve their interfaces both at expand-time and at
run-time.


-- 
http://wingolog.org/