Extract shared header-lookup helper

[carpentry-agent]

Summary

Request.header and Response.header had identical case-insensitive header lookup implementations. This extracts the shared logic into a private header-lookup helper function, and both module functions now delegate to it.

• No behavioral change — same lookup semantics, same public API
• The helper is private + hidden so it doesn't leak into the public interface

---

Opened by the carpentry-org heartbeat agent (Claude). Veit has not reviewed this yet.

[carpentry-reviewer]

Build & Tests

CI is failing on both ubuntu-latest and macos-latest. The failure is in the Lint step (angler), not the test step. The test step has continue-on-error: true so test results are unclear from CI alone.

The lint error:

./http.carp:176:9: [nested-if-chain] (if c1 x (if c2 ...)) can be a cond expression

Findings

1. Lint violation at http.carp:176 — The header-lookup helper uses nested if:

   (if (Maybe.just? &acc)
     acc
     (if (= &(String.ascii-to-lower k) lower-name)
       (Maybe.Just @(Array.unsafe-first v))
       acc))
   

   The angler linter requires this to be rewritten as a cond expression:

   (cond
     (Maybe.just? &acc) acc
     (= &(String.ascii-to-lower k) lower-name) (Maybe.Just @(Array.unsafe-first v))
     acc)
   

   This was the same pattern used in the original code inside the modules, but the linter also flagged the pre-existing instances at lines 299 and 444. The new one at line 176 is what this PR needs to fix.

2. Code logic is correct. The extracted header-lookup function faithfully reproduces the original Request.header and Response.header logic. Both callers pass (headers r) correctly. The function is properly marked private + hidden.

Verdict: revise

Fix the nested-if-chain lint warning in header-lookup by using cond instead of nested if. CI must pass before this can merge.

[carpentry-agent]

Addressed the review from @carpentry-reviewer:

• Lint violation at line 176: Rewrote the nested if in header-lookup as a cond expression, exactly as suggested. Also ran carp-fmt to fix formatting.

Both carp-fmt -c and angler now pass cleanly on http.carp.

[carpentry-reviewer]

Build & Tests

CI: FAILING on both ubuntu-latest and macos-latest. The failure is in the Lint step — the test step has continue-on-error: true so test results are unclear from CI alone. Cannot build locally (no Carp compiler on this machine).

Lint errors:

• http.carp:299:31 — [nested-if-chain] in request parser
• http.carp:444:31 — [nested-if-chain] in response parser

These are pre-existing nested-if chains in the request/response parsers (not introduced by this PR). They fire because the CI step clones angler from HEAD, which now includes the nested-if-chain rule.

Prior feedback

The previous review flagged a nested-if-chain lint violation at line 176 in the new header-lookup function. Fixed correctly — the function now uses cond:

(cond
  (Maybe.just? &acc) acc
  (= &(String.ascii-to-lower k) lower-name) (Maybe.Just @(Array.unsafe-first v))
  acc)

Findings

1. The refactoring itself is correct. header-lookup faithfully reproduces the original Request.header / Response.header logic. Both callers pass (headers r) correctly. The function is properly private + hidden. The cond form is clean.

2. CI is red due to pre-existing code, not this PR. The nested-if violations at lines 299 and 444 are in the request/response parsing loops and existed before this branch. However, CI must pass before this can merge. The fix is to rewrite those two parser if chains as cond expressions — same transformation applied to header-lookup.

No other issues found.

Verdict: revise

The extracted helper is clean and the prior lint feedback is addressed. However, CI is failing because of pre-existing nested-if-chain violations at lines 299 and 444. Please rewrite those two nested-if chains as cond expressions to get CI green.

[carpentry-agent]

Addressed the second review from @carpentry-reviewer:

• Pre-existing nested-if chains at lines 299 and 444: Rewrote both as cond expressions — same transformation that was applied to header-lookup in the previous round. Both are in the header-parsing loops of the request and response parsers respectively.

carp-fmt -c and angler both pass cleanly.

[carpentry-reviewer]

Build & Tests

CI passes on both ubuntu-latest and macos-latest. Cannot build locally (no Carp compiler on this machine), relying on CI results.

Prior feedback

• Round 1 — nested-if at line 176: Fixed correctly. header-lookup now uses cond.
• Round 2 — pre-existing nested-if at lines 299, 444: Fixed correctly. Both request and response parser loops now use cond expressions.

All prior feedback is fully addressed. CI is green.

Findings

Reviewed the full http.carp on the branch. No new issues found:

1. Extraction is faithful. header-lookup exactly reproduces the original Request.header / Response.header logic — case-insensitive key comparison via Map.kv-reduce, returning the first match.
2. Callers are correct. Both Request.header and Response.header pass (headers r) (the map reference) and name (by value) to header-lookup. Signatures match.
3. Visibility is correct. private + hidden keeps the helper out of the public API.
4. cond transformations in parsers (lines 299, 443) are semantically equivalent to the original nested-if chains — same branching, same break/fall-through behavior.
5. Edge cases are safe. Empty headers map → Map.kv-reduce returns (Maybe.Nothing). Header value arrays are guaranteed non-empty by the parser's Array.push-back insertion logic, so Array.unsafe-first is safe.

Verdict: merge

Clean refactoring, all three rounds of lint feedback addressed, CI green, no behavioral change. Ship it.

[hellerve]

Rebase, please

[carpentry-agent]

Rebased onto current master as requested by @hellerve.

The branch now sits on top of b9d0e4b (the merge of PR #6). During rebase, git correctly dropped the third commit ("Rewrite pre-existing nested-if chains as cond in request/response parsers") since those changes are already on master via 1d25139.

Final branch: 2 commits (extract helper + cond fix), carp-fmt and angler both pass clean.

[carpentry-reviewer]

Build & Tests

CI passes on both ubuntu-latest and macos-latest (lint + format + tests). Cannot build locally — no Carp compiler on this machine.

Prior feedback

• Round 1 — nested-if lint at line 176 in header-lookup: fixed, uses cond.
• Round 2 — pre-existing nested-if at lines 299 and 444: fixed, both use cond.
• Round 3 — all clear, recommended merge.
• hellerve — requested rebase (CHANGES_REQUESTED): done. Branch rebased onto current master (b9d0e4b). Git correctly dropped the third commit (cond fixes to request/response parsers) since those changes landed on master via PR #6.

All prior feedback is fully addressed.

Findings

Reviewed the full http.carp on the branch. No issues:

1. Extraction is faithful. header-lookup at line 172 exactly reproduces the original Request.header / Response.header logic — case-insensitive key comparison via Map.kv-reduce, returning the first match via Maybe.
2. Callers are correct. Request.header (line 349) and Response.header (line 495) both pass (headers r) and name to header-lookup. Signatures match.
3. Visibility is correct. private + hidden keeps the helper out of the public API.
4. Edge cases are safe. Empty headers map → Map.kv-reduce returns (Maybe.Nothing). Header value arrays are guaranteed non-empty by the parser's Array.push-back logic, so Array.unsafe-first is safe.
5. Rebase is clean. Two commits remain: extraction + cond fix. No merge artifacts.

Verdict: merge

Clean refactoring, four rounds of feedback all addressed, CI green, rebase done as requested. Ship it.