src/lib.rs: EGraph readonly pub. accessors

[Muxianesty]

The following Pull Request introduces a number of read-only accessors to EGraph.
In order to preserve existing API no other function was changed.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 33 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.46%. Comparing base (afd5c07) to head (0b84220).

Files with missing lines	Patch %	Lines
src/lib.rs	0.00%	33 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #827      +/-   ##
==========================================
- Coverage   81.53%   81.46%   -0.08%     
==========================================
  Files          88       88              
  Lines       24157    24190      +33     
==========================================
+ Hits        19697    19706       +9     
- Misses       4460     4484      +24     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[codspeed-hq]

Merging this PR will not alter performance

✅ 28 untouched benchmarks
⏩ 190 skipped benchmarks¹

---

_{Comparing Muxianesty:egraph_pub_api (0b84220) with main (afd5c07)}

Footnotes

1. 190 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[saulshanabrook]

Hey @Muxianesty so far we have been trying to keep some of these interfaces private in order to not be responsible for breaking users code if we change them internally.

Are there particular features that you need that are currently not exposed?

[Muxianesty]

@saulshanabrook Hey!

I've mentioned a use-case of trying to access rulesets from user-defined commands in a read-only fashion in a Zulipchat thread.

To be even more specific, I am trying to build a set of commands which allows to construct rulesets out of existing rules to overcome the limitations of:
(1) repeat, saturate, etc. working with rulesets, not singular rules;
(2) having to copy existing rules by hand to place them in "synthetic" rulesets to use in saturate.

I've came to the same conclusion that these data structures are better left internal and currently trying to cope without them.

[saulshanabrook]

I've came to the same conclusion that these data structures are better left internal and currently trying to cope without them.

Sounds good! If there end up being a few things that do need to be exposed to create custom schedules let us know. There are some custom schedules in experimental that rely on public APIs, so if they aren't enough we can extend them.

The experimentation sounds interesting and am curious how it ends up working out.

[oflatt]

Seems like this can be closed?