Skip to content

feat(emit): in over a list asks its elements the == they have - #362

Merged
cmj0121 merged 4 commits into
mainfrom
feat/358-in-over-eq
Oct 14, 2026
Merged

cmj0121 merged 4 commits into
mainfrom
feat/358-in-over-eq

Conversation

@cmj0121

@cmj0121 cmj0121 commented Oct 14, 2026

Copy link
Copy Markdown
Owner

Closes #358.

What

x in xs over a list now asks each element the == it has. A declared type goes through its Eq, and a
container, a tuple or an array compares by its parts — the comparison #295 built and in did not call.
E9061 retires.

print [3] in [[1, 2], [3]]      # true
print (2, "y") in [(1, "x")]    # false
print P(2, "b") in ps           # true, through P's Eq

Decisions made here

  • The value looked for is on the left of each comparison — x in xs asks x.eq(e), and stops at the
    first match. It only shows with a hand-written eq; the corpus case prints the order.
  • A map or a set with an aggregate key answers E9052, not a new code. They hash rather than compare, and
    an aggregate has no Hash here. That half of E9061 was never an equality gap, and E9052 is the number a
    map built with such a key already had.
  • An unnamed element with a part of no equality is refused for that part, under the code == gives it
    (E4020, E4038, E4034), in the words of in.

Verified

  • Local gates, one at a time, each read: build fixpoint lint fmt-self error-codes-check seed-gaps refuse reject
    mem-check oracle corpus sanitize-corpus mem-peak examples docs-mirror docs-links docs-zerg docs-refused
    docs-repeat marker-codes chapter-codes deviation-check refusal-cites method-gaps gates treesitter dead-code
    stdlib-test compiler-test check-equal reject-fuzz fmt-corpus behaviour conformance productions suites desugar.
    refuse, reject and mem-check also under /bin/bash.
  • The new mem-check case was red with the value's give-back removed (5850 per round), green after.
  • The abort path was red by hand: with the two holds removed, leaks --atExit on the corpus case reports one
    leak; none with them.

Not verified

🤖 Generated with Claude Code

https://claude.ai/code/session_01N8jd1oK2orM6diHxhvWhC7

    `x in xs` was built for the elements C compares and refused, as E9061,
    for a container and for a declared type that carries an `Eq` — an
    equality that was there and that nothing called. Since #295 every one
    of them has a comparison `==` already writes, so the scan asks it:

    - an aggregate element goes through c_eq_pair, with the value looked
      for on the left of each comparison
    - the list and the value are held across the scan when it runs the
      program's own `eq`, which may abort
    - an unnamed element with a part of no equality is refused for that
      part, under the code `==` gives it, in the words of `in`
    - a map and a set hash rather than compare, so an aggregate key is
      asked of c_hashed_check and answers E9052, as the map itself does

    E9061 retires: its rule, its table row (en and zh-TW) and its two
    refuse cases go together, and the hash half is pinned in their place.

    Closes #358.
    Bumps test-data for codegen/in_over_parts: lists of lists, tuples,
    maps and declared types looked in, with a written `eq` that prints
    its order and one that aborts under a `guard`.
…compare

    Three reject cases, one for each class a part can be in, each holding
    the sentence as well as the code. A mem-check case holds what `in`
    gives back over a list of lists, tuples, maps and a declared type:
    shown red with the value's give-back removed.
    The `[not yet]` said the gap would retire with container equality,
    and it had not. What is left unbuilt is the hash half, which the
    note now names with the code it answers under.
@cmj0121
cmj0121 merged commit 5b5c666 into main Oct 14, 2026
8 checks passed
@cmj0121
cmj0121 deleted the feat/358-in-over-eq branch October 14, 2026 01:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

x in xs still refuses a container or an Eq element that == now compares (E9061)

1 participant