The shared part of a sampler: which actions it can make, and how to ask.

Mirrors tbp/monty/frameworks/actions/action_samplers.py::ActionSampler. Monty's base class keeps the list of action types and, in sample, picks one at random and calls its own sample_<name>; everything else lives in the samplers built on it, which is why this module holds only those two calls.

A sampler here is a struct with an :actions list of the action modules it can make — Monty.Frameworks.Actions.LookDown and friends — and the fourteen sample_<name>/3 functions that the pick dispatches to. The struct's own module is what gets called, so this works for any sampler that keeps that list, without a behaviour to satisfy.

The stream is threaded, not looked up

Monty writes self.action_sampler.sample(self.agent_id, ctx.rng) and mutates ctx.rng in place, so consecutive draws consume one advancing stream. Elixir has no mutable state, so sample/3 answers {action, rng} and the caller threads it. stream/3 is where that thread starts: a policy that has none yet takes one from the context.

Answering the stream rather than reseeding it from the step is not a matter of taste — a policy draws several times in a single step (SurfacePolicy samples a direction, then a distance), and a per-step stream would answer those draws with the same action every time. Neither is it a matter of cost: see scripts/bench_samplers.exs. See docs/monty-differences.md §2.5 for the deviation this leaves and §2.1 for the streams themselves.