Struct Recognised 

pub struct Recognised {
    pub lookups: Vec<Lookup>,
    pub elem: VarId,
    pub body: Core,
    pub row: VarId,
}

A loop whose body looked things up, taken apart.

Why this is a list rather than one lookup

A row that shows two related things is an ordinary shape — corpus/33-awareness.beck renders a person’s whereabouts and their note, so its loop body looks up in two collections — and a rule that refused it would leave the capture in place and the whole collection reconsidered per event, which is the cost the operator exists to remove. So every qualifying lookup gets a join, chained: each takes the previous one’s rows on its left, and the row a body finally reads is nested, {left: {left: x, right: a₁}, right: a₂}.

The chain is not free and the cost is memory rather than time: each join holds one row per left row (§99.5 decision 4), so a body with four lookups arranges the collection four times over. What it is not is the plan choice §99.8 is about — nothing here decides an order, because a lookup is against an index and there is no side to swap.

Fields

lookups: Vec<Lookup>

One per lookup, in the order the joins are chained.

elem: VarId

The element parameter the original body was written over.

body: Core

The loop body, with each lookup replaced by a read of the row that answers it, over a fresh parameter that is the last join’s row rather than the left value.

row: VarId

The parameter body now takes.