To add to your pile of options, because you said "certain error conditions":
perhaps you might `raise` an exception in the db code that gets caught by the
network code (using `with-handlers`). In this way the dependency only runs one
direction (network module imports db module) but the db module can still
propagate messages to the network module (by going "backward" through the
existing calling chain with an exception, rather than "forward" by calling into
the db module).
Here is a toy example of a `db` module that keeps kicking back an exception to
a `network` module until it gets zero, no circularity needed:
#lang racket
(module db racket
(provide f)
(define (f val)
(if (zero? val)
'finally-a-zero!
(raise val))))
(module network racket
(require (submod ".." db))
(let loop ([maybe-err-int #f])
(with-handlers ([integer? loop])
(when maybe-err-int
(displayln (number->string maybe-err-int)))
(f (random 10)))))
(require 'network)
> On May 14, 2018, at 10:28 AM, David Storrs <david.sto...@gmail.com> wrote:
>
> This worked fine until now, but I've gotten to a point where they're
> circular -- the network code needs to receive the chunk and then
> forward it to the DB code, but if certain error conditions come up
> then the DB code needs to tell the network code to re-request the
> data.
>
> There's various ways I could work around this (simplest being to put
> all the functions in one file), but I'm wondering if there's a
> recommended way? C would solve this with a .h file. Perl would solve
> it with function prototypes (or simply be able to sort it out without
> intervention). What is the preferred Racket way, or am I simply not
> thinking about it correctly?
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
