saulshanabrook
commented
1 month ago For example, if there is a rule with facts that depend on Generic1[A] and Generic1[B], and actions that give Generic2[A, B] do we parametrize A and B with every single sort that is registered? How would we limit the infinite recursion then? (i.e Generic1[Generic1[int]], etc).
To make this more specific, I came up with a "reasonable" example of a rewrite that might cause this kind of recursion:
# mypy: disable-error-code="empty-body"
from __future__ import annotations
from collections.abc import Callable
from egglog import *
type IntLike = i64Like | Int
class Int(Expr):
def __init__(self, i: i64Like) -> None: ...
def __add__(self, other: IntLike) -> Int: ...
def __gt__(self, other: IntLike) -> Boolean: ...
def __lt__(self, other: IntLike) -> Boolean: ...
def max(self, other: IntLike) -> Int: ...
converter(i64, Int, Int)
class Boolean(Expr):
def if_[T](self, t: T, f: T) -> T: ...
@function
def eq_fn[T](a: T, b: T) -> Boolean: ...
class Product[T, V](Expr):
def __init__(self, left: T, right: V) -> None: ...
@property
def left(self) -> T: ...
@property
def right(self) -> V: ...
def set_left(self, value: T) -> Product[T, V]: ...
def set_right(self, value: V) -> Product[T, V]: ...
def eq(self, other: Product[T, V], l_eq: Callable[[T, T], Boolean], r_eq: Callable[[V, V], Boolean]) -> Boolean: ...
class Option[T](Expr):
@classmethod
def none(cls) -> Option[T]: ...
def __init__(self, v: T) -> None: ...
def match[V](self, some: Callable[[T], V], none: V) -> V: ...
def map[V](self, fn: Callable[[T], V]) -> Option[V]: ...
class List[T](Expr):
def __init__(self) -> None: ...
def __getitem__(self, index: Int) -> T: ...
def find_index(self, fn: Callable[[T], Boolean]) -> Option[Int]: ...
def fold[V](self, f: Callable[[T, V], V], v: V) -> V: ...
def set(self, index: Int, value: T) -> List[T]: ...
def append(self, next: T) -> List[T]: ...
def most_common(self) -> Option[T]:
"""
Returns the most common element in the list.
If no items are in the list, returns None.
If multiple items are tied for most common, returns the first one.
"""
# 1. Built up list of pairs of elements and their counts
counts: List[Product[T, Int]] = self.fold(
lambda x, acc: acc.find_index(lambda p: eq_fn(p.left, x)).match(
# If we already have a pair for this element, increment the count
lambda i: acc.set(i, acc[i].set_right(acc[i].right + 1)),
# Otherwise, add a new pair with a count of 1
acc.append(Product(x, Int(1))),
),
List[Product[T, Int]](),
)
# 2. Find the highest count
highest_count = counts.fold(
lambda p, acc: Option(
acc.match(
lambda h: (p.right > h.right).if_(p, h),
p,
)
),
Option[Product[T, Int]].none(),
)
return highest_count.map(lambda p: p.left)
def _most_common_definition[T](l: List[T], r: Option[T]):
res = (
l.fold(
lambda x, acc: acc.find_index(lambda p: eq_fn(p.left, x)).match(
lambda i: acc.set(i, acc[i].set_right(acc[i].right + 1)),
acc.append(Product(x, Int(1))),
),
List[Product[T, Int]](),
)
.fold(
lambda p, acc: Option(
acc.match(
lambda h: (p.right > h.right).if_(p, h),
p,
)
),
Option[Product[T, Int]].none(),
)
.map(lambda p: p.left)
)
# the definition of most_common will be turned into this rewrite:
yield rewrite(l.most_common()).to(res)
# which will in turn be turned into this rule
yield rule(eq(r).to(l.most_common())).then(union(r).with_(res))
The way I am understanding the monomorphization approach would be to make multiple version of the most_common rule, one for every possible set of input types.
So if I started with a a type List[Int]() added to the e-graph, and then ran most_common on it, we would definitely need a version of that rule added with T replaced with Int.
Generally, we can think about the facts of a rule as input types and the actions as output types, if we are trying to analyze what types could be further created by applying rules. The only way new types can be added to the e-graph, is in the actions, not in the facts.
So in this rule, in the facts, we have types List[T] and Option[T]. So if we added List[Int]().most_common(some_eq_fn) to the e-graph, then we have types List[Int] and Option[Int], now in the e-graph. So we would monomorphize this function for T being replaced with Int.
But now, in the actions of this function we see we add a number of additional types, including List[Product[Int, Int]] and Option[Product[Int, Int]]. Now if we want to run our monorphization till a fixpoint, we can see we will recurse infinitely here. Now we want to make a most_common where T is Product[Int, Int]. Of course, we can see that we don't actually need this version, because most_common is not called say recursively in the definition of fold or anything. But if we are only looking at the type level and not trying to symbolically evaluate rules to understand which causes which at the value level (which seems infeasible), then we don't know this and we should generate the new definition.
I am only saying all this to give a vaguely realistic example of how this infinite recursion could happen to see if there is any advise on other ways to look at the problem that would allow accurate monorphization of user defined generics. A workaround here would be to cap recursing at a number of levels, say 3, so it would only generate up to three nested definitions or something. However, this would fundamentally be incomplete.
ezrosent
yihozhang
I am opening up this issue to discuss how to support user-defined generics within egglog.
Motiviation
Now that first-class functions are working in the egglog Python bindings and I am starting to use them, it's becoming harder to avoid having user defined generics. For example, here is a somewhat minimal tuple of int's class:
This code has to be repeated for every other tuple (tuple of booleans, tuple of ndarrays, etc).
Not only that, you can see I have two repeated
foldfunctions, one for folding a tuple of ints to ints, and another to bools. The burden is high enough that it makes a whole host of functional programming like tasks quite a chore instead of being relatively smooth.Without user defined generics, it also makes it much less attactive to provide any shareable stdlib like module, with all of these collections, since they are much less general purpose.
A generic Tuple class could look something like this:
Approach
I understand it would be a rather large lift to add them to egglog itself. I started a rough design in this PR https://github.com/egraphs-good/egglog/pull/299 A suggestion there was to try doing all of this as desugaring instead in Python package.
That approach would work something like creating a duplicate actual sort for each instantiation of a generic type and also duplicating all rewrite rules.
I am still a bit unclear on how the details would work though. I assume when we add rules and then run rulesets, we would have to make many instances of each generic type and every rewrite rule that uses it. But it seems hard to know when to stop generating new rules.
For example, if there is a rule with facts that depend on
Generic1[A]andGeneric1[B], and actions that giveGeneric2[A, B]do we parametrizeAandBwith every single sort that is registered? How would we limit the infinite recursion then? (i.eGeneric1[Generic1[int]], etc).If anyone has a sound way of thinking about it, that would be much appreciated.