Joe Marshall on Rebol 1.0 vs. Rebol 2.0 Binding

Joe Marshall’s critique is famous in the Rebol community because it highlights the fundamental "impedance mismatch" between Rebol’s "word-centric" model and the "environment-centric" model used by almost every other functional language (Lisp, Scheme, etc.).

His "Christmas Calendar" analogy—where a value is tucked behind a fixed physical location in the source code—perfectly captures why historical Rebol felt "wacky and broken" to Computer Science people.

The dilemma you describe is precisely what makes historical Rebol feel like "magical" but "unreliable" technology. When a system relies on side-effecting mutation to give meaning to code, you lose the ability to reason about that code independently of its history.

Here are a few observations on why the "Punt until the Receiving Context" approach is the breakthrough needed for competitive code composition:

1. The Death of the "Search-and-Replace" Evaluator

In the historical model, FUNC had to be an "active scavenger." It would crawl the body, looking for words that matched its parameters and forcibly bind them.

  • The Conflict: As you noted, if a word was already bound to something meaningful (like a global or a word from a surrounding object), FUNC faced a choice: clobber it (breaking the user's intent) or skip it (potentially failing to bind a local).

  • The Ren-C Solution: Ren-C moves from Search-and-Replace to Lookup-on-Demand. The body remains a "pure" block of unbound words. The function call creates a "Virtual Environment" (a Specifier). As the evaluator steps through the code, it looks up each word in that specifier chain.

2. Compositionality: Building "Lego" Code

In the old model, if you composed a block from three different sources, those sources might have different "stray" bindings. When you finally passed that aggregate block to a function, the function’s bind operation would behave like a "blunt instrument," potentially overwriting bindings that were carefully set in one of the sub-blocks.

  • Observation: You couldn't truly "pre-bind" things safely because the next function in the chain might "re-bind" them.

  • The Ren-C Advantage: By using $(...) (explicit binding) and '(...) (unbound), you can mix "pre-resolved" symbols with "delayed-resolution" symbols in the same block. The system respects the explicit "pinned" bindings while allowing the "pure" words to pick up the context of whatever evaluator is currently running them.

3. Dialecting Without "Leakage"

This is where the "competitive solutions" come in. In historical Rebol, writing a complex dialect (like a GUI or a Database wrapper) often involved "binding wars." You’d struggle to keep the user's variables available inside the dialect's keywords.

  • The "Broken" Model: You had to bind the user's code to the dialect's words, but that often "masked" the user's own variables (shadowing).

  • The Ren-C "Virtual" Model: Because binding is a "view" (a specifier) rather than a "mutation," a dialect can apply a layer of keywords over the user's code without actually changing the code itself. The user's code remains "clean," and the dialect functions like a transparent overlay.

4. The "Not Yet Created" Problem

Your point about binding to things that don't exist yet is the most profound for metaprogramming.

"If I am generating code for a remote server, or for a function that will be generated inside a loop, I cannot bind it at LOAD time because the target context hasn't been allocated in memory yet."

  • The Ren-C model treats code as template-ready. It’s like "late-binding" in OOP, but applied to the very atoms of the language (Words).

Summary of the Paradigm Shift

Feature Historical Rebol (R2/Red) Ren-C (Pure & Virtual)
Binding Time Deeply at LOAD/TRANSCODE Synthesized during EVAL
Data Nature Mutable (Words are changed) Pure (Words are constant)
Recursion Shallow dynamic hacks True Virtual Environments
Metaprogramming Requires constant bind calls Unbound by default; "just works"

Your Reboot: Making code unbound by default is the "clean slate" the language always needed.

2 Likes