Lift-Pulling Smart Constructors

• Lift-pulling smart constructors are mechanisms that embed lifting into e-graphs, defining context as part of term identity and ensuring α-canonical representations.
• They streamline term construction by detecting common lifting among child nodes and factoring it out to maximize sharing and eliminate redundant context.
• Implemented with fat identifiers and thinning bitvectors, they enable normalization-by-construction that supports efficient variable management in complex rewriters.

Searching arXiv for the primary paper and closely related items mentioned in the supplied data. Lift-pulling smart constructors are a mechanism in the lifting e-graph of “Lifting E-Graphs: A Function Isn’t a Constant” that makes lifting a built-in, normalized part of term construction rather than an explicit syntactic wrapper that accumulates arbitrarily. They are introduced to support variables correctly in e-graphs, especially rigid, $\alpha$-canonical variables, while preserving sharing. Their defining operational behavior is to detect common lifting shared by the children of a new e-node, peel that lifting off, intern the thinner node, and return the result re-lifted in the identifier presented to the caller (Zucker, 22 Jun 2026).

1. Problem setting and purpose

Ordinary e-graphs are designed for ground terms, but real program expressions contain variables. The paper identifies several difficulties that arise if variables are represented naively by names: redundant freshening, hygiene and scope confusion, poor sharing, and ambiguity about which contextual function an expression denotes (Zucker, 22 Jun 2026).

The central conceptual move is that context is part of term identity, not merely external metadata. The paper states: “The context $x,y \mapsto \_$ is not where a term is, it is part of what a term is.” Under that view, $x \mapsto \sin(x)$ and $x,y \mapsto \sin(x)$ are different entities, even though the latter can be obtained from the former by weakening. Lift-pulling smart constructors are introduced precisely to represent that relation compactly while avoiding an explosion of explicit lift wrappers.

Their role is therefore fourfold. They normalize terms modulo the structural laws of lifting, maximize sharing across ambient context sizes, maintain a canonical representation of variable usage, and make lifting “ephemeral” in identifiers instead of explicit syntax. The resulting representation stores a term in the thinnest context consistent with the variables it actually uses, while still allowing larger-context views via thinnings attached to identifiers. The paper remarks that “by being as thin as possible, the dimensionality can play the role of a kind of a nameless free variable analysis.” This gives lift-pulling smart constructors a direct connection to minimal variable support rather than merely syntactic simplification (Zucker, 22 Jun 2026).

2. Functional lifting, thinnings, and fat identifiers

The mechanism is inseparable from the paper’s functional lifting combinator. For a thinning bitvector $t$, the paper defines

$$\mathrm{lift}_t : (\mathbb{R}^{\mathrm{popcnt}(t)} \to \mathbb{R}) \to (\mathbb{R}^{\mathrm{len}(t)} \to \mathbb{R}),$$

where the thinning specifies which arguments are kept. Semantically, a thinning is represented as type Thin = list[bool], with 1 meaning “keep this argument” and 0 meaning “drop this argument.” The helper operations are dom, cod, and identity thinnings, and composition is defined as a weakening composition on bitvectors (Zucker, 22 Jun 2026).

The paper relies on two equations. The first is lift compaction:

$$\forall X,\quad \mathrm{lift}_i(\mathrm{lift}_j(X)) = \mathrm{lift}_{i \cdot j}(X).$$

The second is lift pulling through symbols:

$$\forall X,Y,\quad f(\mathrm{lift}_i(X), \mathrm{lift}_i(Y)) = \mathrm{lift}_i(f(X,Y)).$$

Lift-pulling smart constructors do not leave these equalities to later rewriting; they implement them during construction.

To bake lifting into the e-graph, ordinary identifiers are replaced with fat identifiers: $t$4 A fat id is a pair $(t,i)$ meaning “take e-class $i$, then lift it by $x,y \mapsto \_$0.” Correspondingly, e-nodes store fat children: $t$5 This representation means that lifting is no longer a separate syntax node. Every edge to a child already records how that child is viewed in the parent’s context. The thinning bitvector is therefore simultaneously a context morphism, a usage mask, and a canonical support description. A constant in a four-variable context, for example, is represented as $x,y \mapsto \_$1, indicating that the underlying term really uses no variables (Zucker, 22 Jun 2026).

3. Normalization by construction

The operational meaning of a lift-pulling smart constructor is stated directly in the paper: whenever a new e-node is built, the constructor examines the common lifting of the fat eids of its arguments, peels off this lifting, interns the e-node, and then puts the common lifting back on before returning the fat eid to the user (Zucker, 22 Jun 2026).

For child fat ids $x,y \mapsto \_$2, the behavior is conceptually:

1. compute the largest common pullable lift among the $x,y \mapsto \_$3;
2. factor each thinning as $x,y \mapsto \_$4;
3. intern the residual node $x,y \mapsto \_$5;
4. return $x,y \mapsto \_$6.

This realizes

$x,y \mapsto \_$7

as a normalization policy rather than an ordinary rewrite rule. The paper does not provide full pseudocode for the smart constructor itself, but it describes this behavior explicitly and notes that, even without union-find, “this lifting pulling smart constructor with fat ids makes for an $x,y \mapsto \_$8 aware hash cons.”

The constructor does not eliminate all child thinnings. Residual thinnings remain when different arguments use different subsets of the parent context. What it removes is exactly the common lift that can be factored out without losing information. Thus every interned node is as thin as possible except for irreducible thinnings required to reconcile distinct supports. This is not merely a storage optimization. It is the mechanism by which the e-graph internalizes the distinction between a term’s minimal support and its various larger-context views (Zucker, 22 Jun 2026).

4. Canonical minimal support and representative examples

The invariant maintained by the constructor is that common lifting is pulled as high as possible. The paper’s examples make the resulting normal forms explicit.

Named form	Unnormalized form	Maximally pulled form
$x,y \mapsto \_$9	$x \mapsto \sin(x)$0	$x \mapsto \sin(x)$1
$x \mapsto \sin(x)$2	$x \mapsto \sin(x)$3	$x \mapsto \sin(x)$4
$x \mapsto \sin(x)$5	$x \mapsto \sin(x)$6	$x \mapsto \sin(x)$7

The constant example is the degenerate case: no variables are used, so the term is already maximally independent of context. The sum-of-constants example shows the simplest pure lift-pulling step, where two identical outer lifts are factored upward. The mixed example $x \mapsto \sin(x)$8 shows that once the whole expression is reduced to the one-variable context determined by $x \mapsto \sin(x)$9, the constant still has to be represented as context-independent inside that reduced context, hence $x,y \mapsto \sin(x)$0.

The example $x,y \mapsto \sin(x)$1 is the clearest illustration of the distinction between global and local support. Globally, only $x,y \mapsto \sin(x)$2 and $x,y \mapsto \sin(x)$3 matter, so the entire term is lifted by $x,y \mapsto \sin(x)$4. Inside that reduced two-variable context, the left child uses the first variable and the right child uses the second, so the residual thinnings are $x,y \mapsto \sin(x)$5 and $x,y \mapsto \sin(x)$6. The paper presents this as exactly the normalization that the smart constructor computes (Zucker, 22 Jun 2026).

This representation yields a rigid form of $x,y \mapsto \sin(x)$7-canonicality. Variables are nameless and ordered; context extension is explicit via lifting; and redundant unused variables are eliminated from the interned core. A plausible implication is that the constructor is simultaneously performing canonicalization and a form of free-variable support minimization, but the paper expresses this directly through dimensionality and thinning rather than through a separate analysis pass.

5. Interaction with union-find, correctness conditions, and operational limits

The paper is explicit that smart constructors alone are not enough for a full e-graph. Without union-find, the structure is an $x,y \mapsto \sin(x)$8-aware hash-cons rather than a full congruence-closure engine. The lifting e-graph therefore adds a thinning-aware union-find whose operations mirror the same factorization ideas used by the smart constructor (Zucker, 22 Jun 2026).

Two thinning operations are central: $t$6 and $t$7 The first computes the weakest common thinning by bitwise conjunction; the second factors one thinning through another when one is thinner. The union-find code computes common support, moves to a thinner shared representative, and attaches residual thinnings on parent edges. Structurally, this is the same pattern as smart-constructor lift pulling.

Correctness depends on several semantic constraints. The paper states that liftings are treated as injective:

$x,y \mapsto \sin(x)$9

It also insists on context-sensitive typing discipline: “It does not even type check to union two objects with different numbers of variables. If a lifting mismatch is due to this, it is a user error.” These conditions are not incidental. The factoring and peeling of common lifts depend on the injectivity and dimensional consistency of lifting (Zucker, 22 Jun 2026).

The paper also highlights a central subtlety: equalities discovered globally may reduce support beyond what local smart-constructor normalization can foresee. The canonical example is $t$0, which in contextualized form becomes

$t$1

A one-variable term can therefore collapse to a constant. In such cases the data structure must record a parent relation with a thinning, rather than merely orienting the equality to one side. More complicated cases, such as

$t$2

may require the union-find to create a fresh common parent because neither side’s thinning subsumes the other. This shows the tradeoff stated in the paper: local smart-constructor normalization is necessary but not sufficient once support-reducing equalities enter global reasoning (Zucker, 22 Jun 2026).

E-matching introduces further complications. The paper describes matching as largely pushing lifts downward during traversal, but notes problems arising from redundant parent edges in the thinning-aware union-find. A simpler matcher can ignore such matches; a more complete one must solve thinning equations and may face nondeterminism. This suggests that lift-pulling smart constructors simplify canonical construction, but they do not remove the complexity of global equivalence maintenance and pattern search.

6. Conceptual lineage and related uses of constructor abstraction

The paper explicitly situates lift-pulling smart constructors relative to slotted e-graphs and Co-de Bruijn syntax. It states that the lifting e-graph “can be seen as an approach to taking the slotted notion of redundancy as primary and removing the notion of permutative renaming.” In that comparison, contexts are totally ordered, renaming is restricted to thinning rather than arbitrary permutation, and unused variables are first-class. The paper also notes that a sparse thinning representation listing kept indices rather than using bitvectors would make the connection even tighter (Zucker, 22 Jun 2026).

The relation to Co-de Bruijn syntax is even more direct. The paper says: “Pulling lifts up corresponds in an interesting way to the co-de Bruijn style of normalizing and representing lambda terms as described in McBride’s Everybody’s Got to Be Somewhere.” In both settings, subterms are represented in the smallest context compatible with their support, and weakening is attached only where externally necessary. Lift-pulling smart constructors can therefore be read as a co-de-Bruijn normalization step specialized to e-graph nodes (Zucker, 22 Jun 2026).

The term “smart constructor” is used differently in other arXiv literature, and those differences help delimit the present notion. In “Binary Tree Arithmetic with Generalized Constructors,” recursively defined operations are exposed through apply and unapply so they can be used as if they were constructors in both construction and pattern matching; there the emphasis is on algebraic views and generalized deconstructors rather than context minimization in e-graphs (Tarau, 2013). In “Unboxed data constructors -- or, how cpp decides a halting problem,” certain constructors remain present in the source language and typing while their runtime representation is compiled away to the identity on the payload, with safety enforced by head-shape analysis; that is a representation-level erasure discipline rather than lift normalization over contexts (Chataing et al., 2023). These contrasts suggest that “smart constructor” is a family resemblance term, whereas lift-pulling smart constructors name a specific normalization-by-construction device for rigid, $t$3-canonical variables in lifting e-graphs.

Within that more specific sense, the defining contribution is stable. Lift-pulling smart constructors make context part of term identity, yet preserve sharing by storing interned nodes at minimal support and relegating ambient-context variation to thinnings on edges and identifiers. They implement the algebra of lift compaction and lift pulling eagerly, expose a built-in notion of minimal variable support, and serve as one of the core mechanisms by which lifting e-graphs attempt to support variables correctly (Zucker, 22 Jun 2026).