Skip to content

Rank the Chisel/Studio findings, and record four that were missing (§15) - #177

Merged
kaidesu merged 1 commit into
1.0from
claude/ghost-items-prioritize-f4ghko
Sep 4, 2026
Merged

kaidesu merged 1 commit into
1.0from
claude/ghost-items-prioritize-f4ghko

Conversation

@kaidesu

@kaidesu kaidesu commented Sep 4, 2026

Copy link
Copy Markdown
Member

Overview

The findings from building Chisel and Studio on Ghost arrived as one report (docs/papercuts.md in the Studio repo) and were recorded as §13.13–§13.20 in the order they were written down — which is not the order they should be fixed in. Nothing said which to take first, and four of the report's items had no entry in this document at all.

This re-runs every Ghost item in that report against the interpreter at c31c79d rather than trusting either document, records the four that were missing, and adds §15 to rank what is left. No interpreter behavior changes hereSPEC.md and CLAUDE.md only.

The headline finding is §13.21. and/or do not short-circuit, §8.4 asks for exactly that, and the evaluator obeys — so unlike §13.15 and §13.17 this is not drift, it is a stance. The stance is wrong:

target = null
target == null or target.hint == ''   // property error: cannot read property `hint` of null

That is the null guard Python, Ruby, JavaScript and PHP all teach, and it produces the fault it was written to prevent. Eight real defects in the first library written against Ghost, two of which shipped — one of them crashing on every keypress that had no binding.

Two things make it cheaper to fix here than the same change is elsewhere. Ghost's and/or are boolean-only (1 and 2 is a type error today, not 2), so there is no value-returning question to settle — and cond ? a : b already evaluates one arm, so laziness is not a new concept in this tree-walker:

false and 1   // before: type error - cannot use `and` between boolean and number
              // after:  false     (the unreached operand is no longer type-checked)

Changes

Added

  • §13.21and/or do not short-circuit. Argued against the stance rather than the code, with the fix sketch (evaluateInfix, plus a comment in optimizer/fold.go) and the one behavior that loosens.
  • §13.22 — a method's name shadows a same-named import for every method of its class. Reports a property error at the call site with nothing at the import or the declaration to connect them. Shipped a crash.
  • §13.23 — a function held in a field cannot be called through the field; the mirror image of §13.18.
  • §13.24 — a reserved word is unusable at any call site, not only as a method name: cursors.use('arrow') will not parse, on an object with nothing to do with traits.
  • §14 decision 11 — reverses §8.4's non-short-circuiting rule, with the "operators keep one meaning" argument addressed rather than ignored: short-circuiting does not give and a second meaning, it computes the same one without evaluating an operand that cannot change the answer.
  • §15 — ranks the ten open items by expected damage, cost breaking ties, and lists what is already answered (statics per §14 decision 5; float division, which is not reproducible as stated; the working-as-intended surprises).

Changed

  • §13.20's continue bullet no longer calls the keyword restriction working-as-intended, and points at §13.24 for the call-site half it missed.
  • CLAUDE.md sends a session picking up §13.13–§13.24 to §15's table rather than to the callout numbering, which is chronological rather than ranked.

Fixed

  • Four items in the report are marked closed with the verification behind them: §13.13, §13.14, §13.15 and the list.length hazard no longer reproduce.

Additional context

§13.15's breaking change was checked against the codebase that reported it, not only against examples/. Studio's engine-independent suite — 132 cases — passes unchanged at c31c79d, and Dock.arrange(), the one place that report names as depending on block-free scoping, is directly covered and unaffected: it binds area and taken before the switch, so the destructuring inside each case rebinds them through the walking assignment §14 decision 9 introduced alongside block scoping. The two halves of that decision paying for each other is not theoretical.

Priority order, for review at a glance. #1 §13.21, #2 §13.22, #3 §13.17, #4 §13.18, #5 §13.16, #6 §13.23, #7 §13.24, #8 math.floorDiv, #9 %=, #10 §13.19. #1#4 are four small independent patches that together close every finding whose failure does not point at its own cause; #2 and #4 want the same check at class construction and should land together.

The ranking deliberately promotes §13.21 above findings that have been open longer, and puts §13.16 (highest damage left) at #5 because it is an open design decision rather than a defect with a known patch.

A companion PR on ghost-language/studio re-runs the same items and marks the fixed ones in docs/papercuts.md.

go build ./... and go test ./... are clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EGsNMRiKwWmvoizxD619zA


Generated by Claude Code

The findings from building Chisel and Studio on Ghost arrived as one
report and were recorded as §13.13-§13.20 in the order they were written
down, which is not the order they should be fixed in. Nothing said which
to take first, and four of the report's items had no entry at all.

Re-runs every Ghost item in that report against the interpreter at
c31c79d rather than trusting either document, and records the result:

- §13.21: `and`/`or` do not short-circuit. §8.4 asks for this and the
  evaluator obeys, so it is a stance rather than drift - and the stance
  is wrong. Eight defects in the first library written against Ghost,
  two of them shipped, all of them null guards written the way Python,
  Ruby, JavaScript and PHP all teach them. Ghost's `and`/`or` are
  boolean-only, so short-circuiting here does not raise the
  value-returning question that makes the operator subtle elsewhere, and
  the ternary already evaluates one arm. §14 decision 11 reverses §8.4.
- §13.22: a method's name shadows a same-named import for every method
  of its class, reporting a property error at the call site with nothing
  at the import or the declaration. Shipped a crash.
- §13.23: a function held in a field cannot be called through the field.
- §13.24: a reserved word is unusable at any call site, not only as a
  method name - `cursors.use('arrow')` will not parse. §13.20 had the
  declaration half and called it working as intended; the call-site half
  is not.

§15 then ranks the open items by expected damage, with cost breaking
ties, and marks the four that no longer reproduce - §13.13, §13.14,
§13.15 and the `list.length` hazard. §13.15's breaking change is checked
against the codebase that reported it, not only against examples/:
Studio's 132-case suite passes unchanged, `Dock.arrange()` included.

No interpreter behavior changes here. CLAUDE.md now points a session
picking up §13.13-§13.24 at §15's table rather than at the callout
numbering, which is chronological.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EGsNMRiKwWmvoizxD619zA
@kaidesu
kaidesu marked this pull request as ready for review September 4, 2026 06:12
@kaidesu
kaidesu merged commit 2a0562f into 1.0 Sep 4, 2026
2 checks passed
@kaidesu
kaidesu deleted the claude/ghost-items-prioritize-f4ghko branch September 4, 2026 06:12
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.

2 participants