Actor Like Message Loops
type WorkerMessage =
| Process(Path: String)
| Stop
Status: design-only. Parser: no actor syntax. Interpreter: no public actor runtime. JVM: no public actor runtime. Meris can model messages as closed variants today; owned mailboxes, loop execution, supervision, and public APIs remain future work.
Actor-like message loops are the planned Meris model for local workers and supervisors built on structured concurrency. They are not detached tasks. A future loop must have an owner scope, a bounded typed mailbox, a handler, a supervision policy, cleanup, and a final outcome.
A loop is child work:
parent work scope
owns actor scope
owns mailbox
owns loop state
owns handler work
owns cleanup
Rules:
- a loop cannot outlive its owner unless a future explicit service scope adopts it
- mailboxes are bounded; unbounded queues are rejected for the first design
- accepted messages are delivered FIFO per mailbox
- cross-mailbox ordering is not guaranteed
- parent cancellation closes the mailbox and cancels the loop
- handler typed failures, runtime failures, and cancellation remain distinct
- cleanup runs before the parent scope completes
The first public surface should be a standard-library/runtime API, not syntax.
Names such as Actor.Scope, Actor.Mailbox, Actor.Send, and Actor.Stop
are placeholders until runtime behavior is implemented.
Actor-like behavior must be driven by deterministic tests:
- enqueue accepted and rejected messages without sleeping
- step loop execution one message at a time
- advance fake time for timeout policy
- inject parent cancellation and explicit stop
- assert delivery order, queue-full outcomes, cleanup order, and final outcome
Logs are not assertions; test observations should be data.
No public Java executor, thread, coroutine, servlet, Netty, Ktor, Spring,
CompletableFuture, or Java Flow type may leak into Meris source.
No distributed actors, automatic restart policy, request/reply primitive,
public async/await, or detached work is part of this design slice.