Bringing Algebraic Hierarchical Decompositions to Concatenative Functional Languages

TL;DR

This work addresses the gap between programming languages and algebraic theory by extending Krohn–Rhodes hierarchical decompositions to the realm of concatenative languages through semigroupoids. It formalizes semigroupoids as typed, associative arrow structures and applies a two-level decomposition (collapse-copy-compress) to language representations, enabling an explicit hierarchical view of program structure. The paper introduces a minimal semigroupoid language with precise typing rules and analyzes how to manage infinity via finite top-level representations, illustrated with a binary-addition example and partial transformation models. By surveying concatenative languages (FORTH, Lisp, Joy, Factor) and outlining a concrete plan for modular language design, it sets a foundation for algebraic analysis of program spaces and design choices with potential benefits for correctness, pedagogy, and language evolution.

Abstract

Programming languages tend to evolve over time to use more and more concepts from theoretical computer science. Still, there is a gap between programming and pure mathematics. Not all theoretical results have realized their promising applications. The algebraic decomposition of finite state automata (Krohn-Rhodes Theory) constructs an emulating hierarchical structure from simpler components for any computing device. These decompositions provide ways to understand and control computational processes, but so far the applications were limited to theoretical investigations. Here, we study how to apply algebraic decompositions to programming languages. We use recent results on generalizing the algebraic theory to the categorical level (from semigroups to semigroupoids) and work with the special class of concatenative functional programming languages. As a first application of semigroupoid decompositions, we start to design a family of programming languages with an explicit semigroupoid representation.

Figures (6)

• Figure 1: Schematic explanation of hierarchical decompositions. On the left we have the original system with a complicated structure. For understanding its dynamics, we build another system (on the right) with a hierarchical structure. The decomposition is potentially bigger than the original system. The hierarchical structure emulates the original: we can ask how to do an original action in the hierarchical form. The arrow pointing from the decomposition is interpretation: we can ask what is the meaning (in the original system) of a hierarchical action.
• Figure 2: The parallel between decompositions of the symmetry group of the Rubik's Cube and the decompositions of the program space of a programming language.
• Figure 3: The algorithmic solution space is the set of computer programs solving a computational problem, i.e. realizing a function described by input-output mappings. This schematic diagram emphasizes the space-like nature. Some solutions are closer to each other, others are more different. As programs are complex structures, we cannot measure distance with a single number, but by algebraic structures.
• Figure 4: A semigroupoid with two objects and six arrows. Diagram of objects and arrows on the left, the corresponding composition table in the middle, and the simplified composition table only with the arrow types on the right. The sequence $abaacff$ is typed as the domains match the codomains for each pair in the sequence. However, $bdef$ is not valid $d$ is not composable with $e$.
• Figure 5: The three different ways of writing operators and their operands. Mathematics uses the infix notation. Perhaps due to its familiarity, most programming languages use the same. Languages in the Lisp family use prefix notation. This allows to extend the operators to $n$-ary, e.g., (+ 1 2 3). It also has a uniform structure for arithmetic an function calls. Finally stack-based languages use postfix notation. This does not even need parentheses, but the arity of operators are fixed.

Theorems & Definitions (3)

• Definition 3.1
• Example 3.2: Two-type semigroupoid egrinagy2025minikanren
• Example 5.1