The lookup rules in `Provided` encode the ρ regime and are not marked as such

Open Beginner friendly
#8,161 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
java
Domain
compilers

Research direction

Start with Provided.kept in eo-inference/src/main/java/org/eolang/inference/Provided.java:217, then inspect the lookup rules and Bound's argument handling alongside PhDefault.take. Identify which rules depend on the current receiver conventions and mark each with a docblock line. Done means regime-dependent assumptions are visible and grep-able for the next receiver migration.

Written by the indexing model from the issue text.

Description

enhancement question wontfix

Provided.kept at eo-inference/src/main/java/org/eolang/inference/Provided.java:217 resolves an attribute the way PhDefault.take does today — the type's own cells, then its package, then behind what it delegates to — and Bound places arguments among declared voids under today's receiver conventions. The receiver rework (#6985: a receiver is a declared ^ void) has already forced three corrections — #7743, #7491, #7326 — and each was discovered when a table went wrong, not when the language moved.

The assumptions themselves are not the defect; they were right when written. The defect is that they are invisible: nothing distinguishes a rule that merely reads XMIR from a rule that encodes the current receiver semantics, so every next step of the rework starts with an archaeology dig through the module.

One docblock line per rule that leans on the regime — "assumes the receiver lands in the first free void", "assumes ^ is bound by dispatch" — turns the next migration into a grep.

Dominant language
Java
Stars
1.5k
Forks
251
Avg merge
22h 52m
Merged PRs (30d)
653

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from objectionary/eo

All issues in objectionary/eo

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.