Joe, Check out the "racket/unit" library of dynamic, recursively-linkable components. You can define separate signatures for constraints and connectors, then define a unit implementing each that imports one signature and exports the other, and finally link the two modules together. The unit system will resolve the appropriate recursion. You can then put each of these pieces in a separate module (file) if you like; the implementation units only depend on the interfaces, and only the linked unit depends on both implementations, so the modules will not be cyclic even though the units are.
Carl Eastlund On Tue, Oct 26, 2010 at 10:56 AM, Joe Snikeris <j...@snikeris.com> wrote: > Hi all, > > I've encountered: > > standard-module-name-resolver: cycle in loading at... > > I understand the issue; however, I'm not sure how to resolve it while > maintaining good design. Perhaps my idea of good design is flawed. > Anyway, I'm working on a problem from SICP [1] that involves several > objects: primitive constraints (such as adders, multipliers, > constants) and connectors (which connect primitive-constraints > together). > > I have the primitive constraint procedures defined in one file, and > the connector procedures in another. The connectors use procedures > that operate on primitive constraints and the primitive-constraints > use procedures that operate on connectors. > > So there is a need to require the definitions for connectors in the > primitive constraint file, and vice versa. > > For example, the connectors call a procedure (inform-about-value > constraint) that I've defined in the primitive constraint file, since > it operates on constraints. > > Any advice? > > Thanks in advance, > Joe > > [1] - http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_thm_3.33\ _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
