Module samples 

Built-in demo chunks assembled with crate::Program.

Use these as runnable specs of the messaging contract (and as regression tests). Prefer copying a sample over inventing hop register layouts from scratch.

Sample	Shows
add_forty_two	Scalar VM path (no natives)
ping_pong	Cap spawn + Atomic Hop round-trip
atomic_request_reply	Tagged REQ/REP + correlated receive
atomic_actors	Server loop + two Ask clients + minted request_id
cap_in_payload	Cap in hop payload is reissued to the recipient
selective_receive	ReceiveMatch FIFO skip
ask_reply	Ask RPC hop
ask_timeout_expires	AskTimeout writes Unit when the server stays silent
ask_target_exits	Ask dest is TAG_SYS_EXIT when the server dies first
server_loop	BEAM-style receive → handle → reply loop
named_service	Bytecode register_name / whereis (Cap, not FlowId)
forged_sender_send / forged_sender_ask	S1: forged make_msg sender dies
boom	Immediate trap (supervisor demos)
monitor_down	Monitor → crate::TAG_SYS_DOWN on child exit
waiting_send	WAITING_SEND: second hop parks until the first is received

Hop samples require crate::std_native_table.

Constants

TAG_JUNK

Decoy hop for selective_receive — must be skipped by ReceiveMatch.

TAG_PING

TAG_PONG

TAG_REP

TAG_REQ

Protocol tags for Atomic Hop samples.

Functions

add_forty_two

41 + 1; return — the 60-second sanity chunk.

ask_reply

Atomic request/reply via Ask (RPC hop).

ask_target_exits

Server takes the request and exits; client Ask must not hang.

ask_timeout_expires

AskTimeout against a server that never replies → Unit.

atomic_actors

Canonical Atomic Hop actor demo: one server loop, two clients, each doing N Asks with minted request_ids. Main waits for both DONE hops and returns the sum of the client accumulators (2 * 36 = 72).

atomic_request_reply

Atomic request-reply with crate::Value::Message (one envelope per hop).

boom

Immediate Trap — used to show crate::Supervisor restart.

cap_in_payload

Server receives a Cap in the payload and sends 42 back through it. Exercises hop-time reissue (holder becomes the recipient).

forged_sender_ask

Same security property as forged_sender_send, via Ask.

forged_sender_send

Security regression: forged make_msg sender must not survive Send.

monitor_down

Child sleeps then exits; parent monitors and returns the DOWN reason (0 = normal).

named_service

Server publishes "svc"; client loops whereis until it gets a SEND Cap (not ASK — use Send + Receive, not Ask). Returns 42 (41 + 1). Discovery never exposes a raw FlowId.

ping_pong

Two flows, one Atomic Hop round-trip: main sends a Message to pong, pong replies with payload+1 via msg_reply_cap, main returns that payload (2).

selective_receive

Selective Atomic Hop: server waits for TAG_REQ while a TAG_JUNK hop sits ahead in the mailbox (FIFO skip, not drop).

server_loop

BEAM-style server loop: receive_match → handle → send_reply → repeat.

waiting_send

Client arity 1 (r0 = server Cap) sends two hops; server drains both. With mailbox capacity 1 the second send parks (WAITING_SEND).