> On May 14, 2018, at 4:28 PM, David Storrs <david.sto...@gmail.com> wrote:
>
> My application retrieves chunks of files from the network and writes
> them to disk, as well as writing certain data about them to the
> database (e.g. where they are on disk and where they came from on the
> network).
>
> I've split these functions into separate files:
>
> app/network/chunks.rkt
> app/lib/db/chunks.rkt
>
> 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 may wish to consider Units, the second module system.
It was designed for
— mutually referential references among the pieces
— dynamic loading (they are first-class values)
and the example in the first paper about Units comes with an
example about DBs and Display units that refer to each other
so that they can deal with errors.
See https://www2.ccs.neu.edu/racket/pubs/#pldi98-ff
Ignore the material on types.
;; - - -
A simpler way to fix this problem (with fewer guarantees) is to
use callbacks.
So if
module A contains f, which refers to g from module B
module B contains g and h, and the latter refers to k from A
break the cycle with a callbacks. That is, parameterize f over g,
and wherever you call f, ask users to pass in the function g from B.
— Matthias
--
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.
