AppL is a free-monadic application language for declaring the environment in which domain logic runs. It keeps application setup, state initialization, process structure, configuration, and orchestration separate from the domain behavior itself. This separation makes the application’s top-level responsibilities explicit rather than scattering them through raw IO actions. section 9.1.3
The central constraint is deliberate: AppL may start processes, but the logic executed in those additional processes is LangL, not AppL. A process can perform domain-facing actions such as delays, random-number generation, shared-state access, logging, or database access, yet cannot create further child processes. The resulting hierarchy prevents unbounded thread creation from inside worker logic and gives concurrency a visible architectural boundary. section 9.1.3
AppL is used to describe application-level concerns such as:
- Initializing shared application state before concurrent work begins. section 9.1.3
- Evaluating LangL scenarios from the orchestration layer. section 9.1.3
- Forking declared processes while keeping child process creation out of business logic. section 9.1.3
- Managing configuration and relations among processes without placing specific domain logic in the application layer. section 9.1.3
Meteor reporting application
A reporting channel is first created by evaluating a LangL action. AppL then forks an endlessly repeating astronomer process, while a tracking-center scenario runs against the same channel. The astronomer generates and reports a meteor, pauses for a random interval, and repeats; the tracking center reads the reported meteors, clears the channel, and delays. AppL declares how these activities are arranged, while LangL contains the activities’ operational logic. section 9.1.3
This layering is an architectural choice, not a requirement to split every program into multiple languages. Application-level code can directly call LangL scripts and methods, and all logic could remain in AppL when multithreading is not a concern. The split becomes useful when process boundaries, controlled resource use, and a clear distinction between setup and concurrent business behavior matter. section 9.1.3
AppL scenarios also support controllable failure handling and tests. A game-loading scenario combines database operations with application-state variables; replacing an implicit error with a domain exception and running each loading action through runSafely yields an Either result. That refactoring changes the scenario’s call structure, so a white-box test may need to combine mocks with real interpreter steps to reach calls now nested inside runSafely. section 15.2.3
Figure 9.5 Free monadic languages organized hierarchically
The hierarchy diagram makes the boundary visible: AppL occupies the orchestration layer, and LangL scripts supply the logic evaluated within declared processes. section 9.1.3
