When if is just a function

Rye / REBOL model: words, blocks, and “if as function”

• Discussion connects Rye’s design to REBOL, Lisps, Tcl, Smalltalk, Io, etc.
• In Rye/REBOL, blocks {...} are values and are not evaluated by default; control constructs like if, either, loop, for are just functions that decide when to evaluate blocks.
• Word types (set-word word:, get-word ?word, mod-word ::word, operator words, pipe-words) encode assignment, reference, and operator behavior; this is seen as both powerful and non-obvious.
• Some appreciate the conceptual consistency and homoiconicity; others find the word zoo and operator conventions hard to learn.

Looping, scope, and injected blocks

• Loop examples using injected variables (e.g. loop 3 { ::i , prns i }) confused some readers: questions about double-colon semantics, scoping, and whether point-free loops are possible.
• Author clarifies: plain block evaluation does not create a new scope; :: exists because set-words create constants, so loops need a “modifiable” word type that can survive across iterations and in outer scopes.
• Separate “context” primitives exist for explicit scoped evaluation or functional-style loops.

Combinators and functional control flow

• Several comments show how conditionals can be expressed as higher-order functions / combinators in Lisps, Janet, Clojure, Haskell (Church encoding), and via cond-like abstractions.
• Tacit / point-free languages (J, BQN, Uiua, Forth, Factor) are recommended for people wanting to be forced into combinator-style thinking.
• Excel and Smalltalk are noted as real-world examples where if is effectively a method/function.

Evaluation, reflection, and first-class blocks

• Some argue that making if et al. into regular functions requires unevaluated arguments (lazy-by-argument / fexpr-like behavior) and raises closure, return/break, and static-analysis challenges.
• Others respond that these issues mirror those of first-class functions and closures in general, which many languages already embrace.
• There is debate over whether such flexibility encourages “clever”, harder-to-maintain code or simply reduces the number of special forms and makes control flow more uniform.

Criticism of the article’s Python comparison

• A strong subthread claims the article misrepresents Python by ignoring conditional expressions and list comprehensions, where if already behaves expression-like and is composable.
• The author replies that having special syntax for if expressions does not make if a first-class function in Python and that the goal was comparison, not criticism.