loop:
    match J2.next():
        None: break
        Some(w):
            answers.insert((w.Actor, w.Schedule, w.Address))

The action after a return is always the same. The consumer is not making a new decision between these results.

Perform the action and continue its loop. It would no longer have to return one tuple and wait for an immediate request to resume.

We would need another way to stop early if the consumer later wanted that.

Use its Theater to look up Location. For each address, send the projected actor, showing time, and address to the result collector.

Then continue to the next showing for the current movie.

for u in scan(M):
    for v in lookup_P(u.Title):
        for w in lookup_L(v.Theater):
            answers.insert((u.Actor, v.Schedule, w.Address))

Those are the same nested lookups. But a completed match now continues directly into the action that uses it.

First (actor1,18:00,addr1), then (actor1,21:00,addr1). Only then does the outer loop move to actor2.

The trace agrees with the pull plan's first two results.

It is still needed by the inner loop. The loop and its local variables now hold the progress that the resumable join previously stored between calls.

We changed where control waits. We did not make iteration stateless.

Yes. That would be push execution, with a runtime call to the consumer. It would not yet be a query compiler.

No. Its plan and attribute choices stay fixed while the tuples change. That repeated interpretation is a possible cost of this implementation.

It could put the chosen tests and field accesses directly in the loop body. Then the loop would operate on the tuple values without asking what kind of plan node to interpret each time.

That motivates specialization. It does not tell us whether its cost will pay off for a small query.

No. The plan already describes the required operations. We need to turn those descriptions into code systematically.

That is the compiler's job. How does it compose the pieces?

It emits a loop over Movies, then places the code generated by $k(u)$ inside that loop:

for u in M:
    <code generated by k(u)>

Here u is a name in the program being generated. We are not reading one particular Movies tuple during compilation.

An if whose body contains the consumer's code:

for u in M:
    if u.Director == "Bergman":
        <code for the selected tuple's consumer>

answers = empty_set()
for u in M:
    if u.Director == "Bergman":
        answers.insert(u.Title)

Actor1 inserts filmA. Actor2 inserts filmA again, leaving the set unchanged. Actor3 fails the condition. The answer is {filmA}.

Then I emit filmA twice. Fusing the operations did not give permission to drop duplicate elimination from relational projection.

I was about to say yes. But it generated the loop body. That body runs for actor1 and actor2 later.

The compiler's traversal of the plan and the generated program's traversal of tuples are different computations.

The Movies schema, the selected Director field, the constant Bergman, and the requested Title field. The actual movie values arrive at runtime.

That matches R.3: leave runtime holes in the program we construct.

The collector generates insertion of (Actor,Schedule,Address).

$J_2$ asks $J_1$ to produce a tuple, then generates a Theater lookup loop around that insertion. $J_1$ asks the Movies scan to produce a tuple, then generates a Title lookup loop around $J_2$'s code.

The result is the three nested loops we traced. We reached them through the physical plan.

No. Actor1 has two showings. Existence would tell us that at least one exists, but it would not enumerate both times.

Changing control flow must preserve the access contract too.

Both search the same showing array for the same Title. We still need both actors' matches, but we could share the work of organizing Pariscope.

A build loop over Pariscope:

H = empty_map_of_lists()
for v in P:
    H[v.Title].append(v)

for u in M:
    for v in H.get_or_empty(u.Title):
        for w in lookup_L(v.Theater):
            answers.insert((u.Actor, v.Schedule, w.Address))

The table keeps both filmA showings. Keeping one would lose an answer.

No. The 21:00 showing has not arrived yet. This build-then-probe algorithm must finish the build before the probe phase uses the table as complete.

Push execution did not remove that dependency.

The hash table of build tuples, or references to them. Not the complete movie–showing join result.

The probe phase can still pass each joined tuple directly into the Location lookup.

The consumer must signal that it is finished, and the loops must propagate that signal outward. Breaking only the Location loop would let the next showing continue producing answers.

Early termination is part of the control protocol, not an automatic consequence of this loop syntax.

We have proved no timing claim. It may avoid calls and keep values close to their uses. It also costs time to generate and compile code.

A compiler may inline a pull implementation too. We must inspect or measure the implementations we actually compare.

Both versions try the two showing matches and find two empty Location lookups. Both return the empty answer set.

The pull call works internally until it returns None. The push loops finish without inserting anything. Empty output does not mean no work.

That is another choice. It does not follow from choosing pull or push.

We can now ask separately which tuples are required, how to find them, and who drives the next step.