How should I avoid cyclic dependency between application state and asynchronous worker?

[amano-kenji]

The custom event type is asynchronous worker's response. I want the response to contain the current state. If the current state contains form, it depends on the worker response type. Worker request and worker response now depend on application state. This creates circular dependency between worker and the part of application state that has form.

If worker response doesn't contain the current state, I have to check whether the current application state matches the response. If the current state is not appropriate for the response, it is an error. This error checking adds a substantial amount of boilerplate.

How should I cut the cyclic dependency?

[jtdaugherty]

It might be really helpful if you could provide at least a sketch of the concrete data types you're using. I'm having a hard time understanding your situation without more information, and it also isn't clear to me why these circular dependencies are problematic in your situation. (Mutually recursive types are common in Haskell, so that isn't inherently problematic.)

[amano-kenji]

module Mode.Pair where

import Worker
import ...

data State = State {
  parent :: Mode.Pairs.State
, old :: Pair
, form :: Form Pair WorkerResponse WidgetName
} deriving Generic

module Worker where

import qualified Mode.Pair

data WorkerRequest =
  MigrateDB Connection |
  ModifyPair {
    state :: Mode.Pair.State
  , pair :: Pair
  }

data WorkerResponse =
  DBMigrated |
  DBMigrationFailed Text |
  ModifyPairResult {
    pair :: Either Text (Pair, [Pair]))
  , state :: Mode.Pair.State
  }
  deriving (Show, Eq)

Circular dependency between haskell modules is a compiler error.

• If WorkerResponse contains state, I can just restore state from the response.
• If it doesn't, I have to check whether the current state is appropriate for the response.
• There might be a third way I don't know.

[jtdaugherty]

Oh, I see - you didn't mention module dependency in your original post. There are three approaches that come to mind for me:

1. Use an .hs-boot file to make the circular dependency compile. This is a good approach when the modules involved must not be combined for some reason, but I personally try to avoid boot files unless there's no better way.
2. Combine the data type declarations in one module so that they aren't spread out in a way that causes the mutual module dependency. This is a really common approach, e.g. make MyPkg.Types, put the types in there, then import MyPkg.Types in both of the modules that would have otherwise depended on each other.
3. Abstract some of the data types in a way that they don't mention (and thus depend on) the concrete data types that create a circular dependency, e.g. Worker would become Worker s and would be abstract over the application state type s rather than using the concrete type it uses currently. This would only work if the worker logic is really generic or can be parameterized with a function s -> s that takes care of the state updates.

Also, in case it helps: the worker's responses should not use actual state values; they should provide state transformations in the form of a pure function (s -> s) or a monadic value (EventM ...). This is important because the state modifications that the worker wants to make need to be made (ultimately) on the state value that is threaded through the event loop, and the worker does not have access to that. Since it sounded to me like you're planning on returning actual state values, I thought I'd mention this.

[jtdaugherty]

When I've done this sort of thing (as I have many times), my worker usually sends an EventM in its response which is then evaluated in the event loop, or the worker just sends data its responses and then the event loop does whatever it needs to do with that data.

[amano-kenji]

Combining the data types in one module should work although it is not ideal.

Returning state transformation in worker response is not desirable because it makes me write a case statement for data constructors of app state. I'm trying to avoid case statement.

The assumption is that an asynchronous job occurs only for a certain data constructor of app state type.

data AppState =
  Pair PairState |
  Top TopState

data PairState = PairState {
  parent :: TopState
, form :: Form Pair WorkerResponse WidgetName
}

With this, a worker request and a worker response may carry PairState.

[amano-kenji]

I just read your matterhorn codebase. It seems you avoid case statement over state type data constructors by using prism.

I can send the current state in a worker request or use prism in EventM.

[jtdaugherty]

I'm not sure what you mean by "avoid case statement." We use lenses in EventM to update state fields, and we send EventM values over the worker's response channel and then evaluate those EventM actions in the main event loop.