Skip to content

feat(emit): two tuples or two arrays order by their parts - #366

Merged
cmj0121 merged 4 commits into
mainfrom
feat/360-tuple-ord
Oct 14, 2026
Merged

cmj0121 merged 4 commits into
mainfrom
feat/360-tuple-ord

Conversation

@cmj0121

@cmj0121 cmj0121 commented Oct 14, 2026

Copy link
Copy Markdown
Owner

Closes #360.

What

Two tuples, or two arrays, order with < <= > >= by their parts, as docs/core/types.md already said:
the first part that differs decides, and nothing after it is read.

print (1, 2) < (1, 3)            # true
print ("apple", 2) < ("banana", 1) # true
print (1, 2.5) < (1, 3.5)        # E3044 … and a float has no `Ord`

Decisions made here

  • Built, not marked [not yet]. The issue allowed either; the == half was built in two containers compare with == and != #295 with the same
    binding and holding, so the ordering reuses that lowering and only the test differs.
  • The four operators come from one less, as Ord's do (a <= b is not (b < a)), so each operand is
    evaluated once. A part is asked < both ways to tell "differs" without asking == too.
  • What orders as a part: an integer of any width, a str, a type with an Ord, or a tuple / array whose
    parts do. A float does not (a NaN breaks a total order, which is why it sits out Ord), and neither does a
    bool.
  • A part without an order is refused for that part, under E3044 — the same rule as two operands that are
    not numbers, so one report site with a different subject (error-codes-check holds one site per code).
  • Lists, maps and sets still have no order. The chapter names a tuple and an array only.

Verified

  • Local gates, one at a time, each read, after the last change: 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. reject and mem-check also under /bin/bash.
  • The new mem-check case was red with the left operand's give-back removed for an ordering (780 per round),
    green after.

Found on the way, not fixed

  • docs/core/specs.md says impl Ord for P is E3013 no spec named Ord; the corpus case writes
    impl Ord for V and it builds and dispatches. That [not yet] looks stale for Ord.
  • sort or a T: Ord bound over a tuple was not measured.

Not verified

  • make test as one board was not run.

🤖 Generated with Claude Code

https://claude.ai/code/session_01N8jd1oK2orM6diHxhvWhC7

    The types chapter gives an unnamed form `Ord` when every part has it,
    and `(1, 2) < (1, 3)` was E3044. A tuple and an array now order
    lexicographically: the first part that differs decides, and nothing
    after it is read.

    - the four operators come from one `less`, as `Ord`'s do, so `a <= b`
      is `not (b < a)` and each operand is evaluated once
    - the operands are bound and held the way `==` binds them, through
      the same lowering, which now picks its test by operator
    - a part orders when it is an integer of any width, a `str`, a type
      with an `Ord`, or a tuple or array whose parts do; a `float` does
      not, a NaN breaking a total order
    - one with a part that does not is refused for that part, under E3044

    A list, a map and a set still have no order.

    Closes #360.
    Bumps test-data for codegen/tuple_order.
    Three reject cases — a `float` part, a part with `Eq` and no `Ord`,
    and a part found inside an array of tuples — each holding the part's
    name. A mem-check case holds what an ordering gives back over owned
    tuples, a declared part and arrays: shown red with the left operand's
    give-back removed.
    The rule's `Ord` half is built; the paragraph after it says how a
    tuple orders and what a part without an order is refused as.
@cmj0121
cmj0121 merged commit d240629 into main Oct 14, 2026
8 checks passed
@cmj0121
cmj0121 deleted the feat/360-tuple-ord branch October 14, 2026 07:46
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.

the types chapter gives a tuple Ord by its parts, and (1, 2) < (1, 3) is E3044

1 participant