Thread Wraps and Stack Frames

A Woolly Bugger starts with a bare hook. You wrap thread to create a foundation, tie in marabou for the tail, dub the body, palmer the hackle forward, then whip-finish the head. Each step assumes the previous one exists — you can’t tie in hackle before the body gives it something to wrap around.

Forth works the same way. Every operation consumes values from the stack and leaves results behind for the next word to use. There’s no way to reference something that isn’t already sitting there, waiting.

: WRAP-THREAD   ( hook -- thread-base ) 1 + ;
: TIE-MARABOU   ( thread-base -- tailed ) 1 + ;
: DUB-BODY      ( tailed -- bodied ) 1 + ;
: PALMER-HACKLE ( bodied -- hackled ) 1 + ;
: WHIP-FINISH   ( hackled -- fly ) 1 + ;

: WOOLLY-BUGGER ( hook -- fly )
  WRAP-THREAD      \ hook becomes thread-base
  TIE-MARABOU      \ thread-base becomes tailed
  DUB-BODY         \ tailed becomes bodied
  PALMER-HACKLE    \ bodied becomes hackled
  WHIP-FINISH ;    \ hackled becomes fly

Each word transforms whatever’s on top. The hook enters, gets modified by each operation in sequence, and emerges as a completed fly. Forth programmers call this “concatenative” — you’re gluing transformations together, trusting that each one leaves the stack in a state the next one can use.

Kotlin’s let chains do something similar, though with explicit naming:

data class Hook(val materials: List<String> = emptyList())
data class Fly(val materials: List<String>)

fun wrapThread(hook: Hook): Hook =
    hook.copy(materials = hook.materials + "thread")

fun tieMaterial(hook: Hook, material: String): Hook =
    hook.copy(materials = hook.materials + material)

fun dubBody(hook: Hook, material: String): Hook =
    hook.copy(materials = hook.materials + "body:$material")

fun palmerHackle(hook: Hook): Hook =
    hook.copy(materials = hook.materials + "hackle")

fun whipFinish(hook: Hook): Fly = Fly(hook.materials + "whip finish")

fun woollyBugger(hook: Hook): Fly =
    hook.let { wrapThread(it) }
        .let { tieMaterial(it, "marabou") }
        .let { dubBody(it, "chenille") }
        .let { palmerHackle(it) }
        .let { whipFinish(it) }

The it pronoun carries state forward, each transformation feeding into the next. You could inline everything into one expression, but the sequential structure mirrors how tying actually happens — you can’t skip ahead, and you can’t undo without cutting thread.

The difference: Forth’s stack is implicit and untyped. If you push a number when the next word expects an address, nothing stops you until runtime. Kotlin’s type system catches that at compile time. The fly tier’s equivalent is realizing you’ve wrapped the hackle backward only after you’ve whip-finished — some mistakes don’t reveal themselves until you’re done.

Charles Moore designed Forth in the late 1960s for controlling radio telescopes. He wanted something small enough to fit in memory, fast enough for real-time control, and simple enough that a single person could understand every line. That constraint — one stack, no hidden state — forces you to think about data flow the way a fly tier thinks about material sequence: what exists now, what the next step needs, what gets left behind.