Cycle in loading. Units, (sub)modules, files...

86 views
Skip to first unread message

Jonas Winje

unread,
Jan 6, 2016, 9:16:32 AM1/6/16
to Racket Users
Hello people,

I've been fumbling around with cyclic dependencies and such and have started looking at signatures and units. I manage to make the cycles work out in a couple different ways, but I'm running into trouble when I try to put different parts in different files the way I want them. As far as I can tell it has to do with how much of a file/module is "loaded" if I really just want to require one of its submodules. Not particularly certain.

It's pretty possible that I'm just doing everything wrong and backwards, or should really not be trying to do this to begin with, or something :)

So: Does anyone know if it is possible to do something along the lines of

- a.rkt with two submodules:
- a-sig: provides signature a^
- a-impl:
- requires a-sig
- requires b-sig from b.rkt
- provides unit a@ (which imports b^ and exports a^)
- b.rkt with two submodules:
- b-sig: provides signature b^
- b-impl:
- requires b-sig
- requires a-sig from a.rkt
- provides unit b@ (which imports a^ and exports b^)

without getting

standard-module-name-resolver: cycle in loading
at path: ...\dep\b.rkt
paths:
...\b.rkt
...\a.rkt

?

I get it to work by putting all 4 modules in the same file. And I get it to work by putting them in 4 different files. But if I want one file for both the a-things and one for both the b-things I get the error above. Presumably because (a submodule in) "a.rkt" requires (a submodule from) "b.rkt", and other way around. (Even though the "b.rkt"-submodule required in "a.rkt" does *not* require anything from "b.rkt", and other way around.)

Examples:
* seems to work: https://gist.github.com/Glorp/c36bcb3af0d8586ec733
* doesn't seem to work: https://gist.github.com/Glorp/86e59ced2bd838d2161c

Daniel Feltey

unread,
Jan 8, 2016, 7:51:41 AM1/8/16
to Jonas Winje, Racket Users
This doesn't quite answer your question, but another possibility that would allow you to separate the a@ and b@ unit implementations in separate files is to put all of your signature definitions in a single file that will be required by both "a.rkt" and "b.rkt". In my experience, this strategy is fairly common in uses of units in the Racket codebase (for example see https://github.com/racket/games/blob/master/gobblet/sig.rkt).

Dan


--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jonas Winje

unread,
Jan 8, 2016, 2:08:37 PM1/8/16
to Daniel Feltey, Racket Users
Thanks. And like, that sounds a lot more sensible than what I'm trying to do :)

And what I'm trying to do doesn't strike me as generally a good idea, but...

Initially I was playing around with language-stuff. Was making a language and wanted a file written in that language to define a signature and a unit exporting it. And I wanted to make it possible to have a file written in that language "require" another file written in the language, only it'd mean something like: B requires the signature-part of A, and it's only required in the unit-part of B.

Very possibly bad idea though :)
Reply all
Reply to author
Forward
0 new messages