Address Class A Accretive failures (#275)

Author: keiravillekode

accretive-audit.md

@@ -47,42 +47,44 @@ Run it with `FACTOR=/path/to/factor bin/check-accretive [slug...]`.
 
 ## Results
 
-The initial audit found 11 of 47 not Accretive. The 5 Mode-B exercises have
-since been fixed (test-only changes); 6 remain open (5 Mode A + 1 structural).
+The initial audit found 11 of 47 not Accretive. The 5 Mode-B and 5 Mode-A
+exercises have since been fixed; only the 1 structural case remains open.
 
 | Verdict | Count | Exercises |
 |---|---|---|
-| Accretive | 41 | all others |
-| Mode A (open) | 5 | bering-bearings, boatswains-bilge, dragons-descendants, factory-failsafe, pirates-path |
+| Accretive | 46 | all others |
+| Mode A (fixed) | 5 | bering-bearings, boatswains-bilge, dragons-descendants, factory-failsafe, pirates-path |
 | Mode B (fixed) | 5 | garden-gathering, lighthouse-logbook, poetry-club, quayside-crew, tellers-triage |
 | Structural (open) | 1 | telegraphers-tape |
 
-## Mode A — a definition is introduced after task 1
-
-- **factory-failsafe** — `ERROR: machine-error` is created in task 3, but the
-  tests reference `machine-error` / `machine-error?` (tasks 3–4). The stub only
-  has a comment, so tasks 1–2 cannot compile.
-  *Fix:* pre-ship the error class in the stub, exactly as `rpn-calculator`
-  already ships `zero-divisor-error`.
-- **pirates-path** — `gold-count` (a `MEMO:` word, task 4) is left as a comment
-  in the stub instead of a stub body, so the tests reference an undefined
-  `gold-count` and nothing compiles.
-  *Fix:* pre-stub it, e.g. `MEMO: gold-count ( cove -- n ) "unimplemented" throw ;`.
+## Mode A — a definition was introduced after task 1 (fixed)
+
+- **factory-failsafe** — `ERROR: machine-error` was created in task 3, but the
+  tests reference `machine-error` / `machine-error?` at compile time, so tasks
+  1–2 could not compile. *Fixed* by reordering so defining the error class is
+  task 1; the check/monitor tasks follow.
+- **pirates-path** — `gold-count` (a `MEMO:` word, task 4) was a comment in the
+  stub, so the tests referenced an undefined `gold-count`. *Fixed* by shipping it
+  as a `:` stub; task 4 now asks the student to change `:` to `MEMO:`.
 - **dragons-descendants** — the subtuples `fire-dragon` / `ice-dragon` /
-  `volcano-dragon` and their constructors are defined across tasks 2–4 (the stub
-  is comment-only), so implementing only task 1 leaves them undefined.
-  *Fix:* bundle all tuple/constructor definitions into task 1.
-- **bering-bearings** — tuples `polar` (task 2) and `relative` (task 3), plus the
-  direction symbols and the `>cartesian`/`flip` generics, are scattered across
-  tasks (comment-only stub).
-  *Fix:* bundle all tuple/symbol/generic definitions into task 1.
+  `volcano-dragon` and their constructors were defined across tasks 2–4 (the stub
+  was comment-only). *Fixed* by bundling the whole tuple hierarchy into task 1
+  (the student still defines it); the descendant constructors are pre-stubbed so
+  the file compiles.
+- **bering-bearings** — the `polar`/`relative` tuples, direction symbols, and the
+  `>cartesian`/`flip` generics were scattered across tasks. *Fixed* by bundling
+  all the data and generic declarations into task 1; the per-class methods stay
+  in their own tasks.
 - **boatswains-bilge** — task 5's `valve` tuple, `<valve>` constructor, and
-  `is-open` slot are not declared; the tests reference `<valve>`/`is-open>>`, so
-  tasks 1–4 cannot compile. (Tasks 1–4 themselves use a `test-pump` fixture
-  defined inside the test file and are otherwise fine.)
-  *Fix:* pre-ship the valve skeleton in the stub —
-  `TUPLE: valve < disposable is-open ;`, a stubbed `<valve>`, and `M: valve
-  dispose* drop ;` — so the file compiles; task 5 fills in the bodies.
+  `is-open` slot were not declared; the tests reference `<valve>`/`is-open>>`, so
+  tasks 1–4 could not compile. *Fixed* by pre-shipping the valve skeleton
+  (`TUPLE: valve < disposable is-open ;`, a stubbed `<valve>`, and `M: valve
+  dispose*`); task 5 fills in the bodies.
+
+`factory-failsafe`, `dragons-descendants`, and `bering-bearings` now rely on a
+task-1 definition to compile (like `lasagna` and `role-playing-game`): the bare
+stub does not compile on its own, which `bin/check-accretive` recognises via its
+`ACCRETIVE_VIA_TASK1` list.
 
 ## Mode B — an early task's test called a later task's word (fixed)
 

bin/check-accretive

@@ -50,7 +50,8 @@ MAPS = {
  "character-study": {"compare-chars":1,"size-of-char":2,"change-size-of-char":3,"type-of-char":4},
  "coordinate-choreography": {"translate-2d":1,"scale-2d":2,"compose-transformations":3,"apply-transformation":4,"transform-points":5},
  "currency-conversion": {"exchange-money":1,"get-change":2,"value-of-bills":3,"number-of-bills":4,"leftover-of-bills":5,"exchangeable-value":6,"safe-change":7,"cap-spend":8},
- "factory-failsafe": {"check-humidity":1,"check-temperature":2,"monitor":4,"monitor-batch":5},
+ "dragons-descendants": {"<dragon>":1,"<fire-dragon>":2,"<ice-dragon>":3,"<volcano-dragon>":4,"age-dragon":5},
+ "factory-failsafe": {"check-humidity":2,"check-temperature":3,"monitor":4,"monitor-batch":5},
  "ferry-schedule": {"make-date":1,"weekday-name":2,"leap?":3,"month-length":4,"add-days":5},
  "garden-gathering": {"open-garden":1,"list-registrations":1,"register":2,"release":3,"get-registration":4,"find-by-name":5},
  "high-school-sweetheart": {"cleanupname":1,"firstletter":2,"initial":3,"couple":4},
@@ -84,12 +85,13 @@ MAPS = {
 # bodies cannot be re-stubbed with a throw, and exercises without TASK: markers
 # have no prefixes). Mode A is still checked for them.
 MODEB_SKIP = {"signal-stencils", "telegraphers-tape", "bering-bearings",
-              "boatswains-bilge", "dragons-descendants"}
+              "boatswains-bilge"}
 
 # The shipped stub does not make the test file compile, but the missing
 # definition is created in task 1, so the exercise is still accretive by the
 # implement-first-K-tasks rule (a student who does task 1 sees task 1 pass).
-ACCRETIVE_VIA_TASK1 = {"lasagna", "role-playing-game"}
+ACCRETIVE_VIA_TASK1 = {"lasagna", "role-playing-game", "factory-failsafe",
+                       "dragons-descendants", "bering-bearings"}
 
 DEF_STARTERS = {":","::","M:","M::","TYPED:","TYPED::","MEMO:","MEMO::"}
 

exercises/concept/bering-bearings/.docs/instructions.md

@@ -20,13 +20,24 @@ Your job is to convert all three into a common cartesian `(x, y)`
 frame so the chart can be plotted. Bearings are degrees; `(0, 1)`
 is one nautical mile north, `(1, 0)` is one nautical mile east.
 
-## 1. Cartesian for cardinal
+## 1. The data model, and cartesian for cardinal
 
-Define a tuple `cardinal` with one slot, `direction`, holding
-one of `north`, `east`, `south`, `west` (declared with
-`SYMBOLS:`). Then declare a `GENERIC:` word
-`>cartesian ( direction -- x y )` and add an `M: cardinal`
-method that returns the unit-vector for the named direction.
+First lay out the pieces the whole exercise shares:
+
+- Define three tuples: `cardinal` (one slot, `direction`), `polar`
+  (slots `magnitude` and `bearing`), and `relative` (slots
+  `distance` and `bearing`).
+- Declare the heading symbols with `SYMBOLS:`: `north`, `east`,
+  `south`, `west`, `ahead`, `starboard`, `behind`, `port`.
+- Declare a dynamic variable `heading` with `SYMBOL:` (task 3 uses
+  it).
+- Declare two generic words —
+  `GENERIC: >cartesian ( direction -- x y )` and
+  `GENERIC: flip ( direction -- direction' )`. You add their
+  methods over the next tasks.
+
+Then add the `M: cardinal` method of `>cartesian`, returning the
+unit-vector for the named direction.
 
 ```factor
 T{ cardinal { direction north } } >cartesian . .
@@ -37,9 +48,8 @@ T{ cardinal { direction north } } >cartesian . .
 
 ## 2. Cartesian for polar
 
-Define a tuple `polar` with slots `magnitude` and `bearing`
-(degrees clockwise from north). Add an `M: polar` method to
-`>cartesian` that converts the polar form to `(x, y)`:
+Add an `M: polar` method to `>cartesian` that converts the polar
+form to `(x, y)`:
 
 ```
 x = magnitude * sin(bearing-in-radians)
@@ -54,17 +64,13 @@ T{ polar { magnitude 10 } { bearing 90 } } >cartesian . .
 
 ## 3. Cartesian for relative
 
-Define a tuple `relative` with slots `distance` and `bearing`
-(one of the symbols `ahead`, `starboard`, `behind`, `port`).
-Add an `M: relative` method to `>cartesian`. The catch: a
-relative bearing is measured against the ship's *current
-heading*, which isn't part of the tuple.
-
-Declare a dynamic variable `heading` (with `SYMBOL:`). The
-caller will set it inside a `with-variable` block. Your method
-reads it with `heading get`, adds the bearing offset
-(`ahead = 0`, `starboard = 90`, `behind = 180`, `port = 270`),
-and produces the cartesian point.
+Add an `M: relative` method to `>cartesian`. The catch: a relative
+bearing is measured against the ship's *current heading*, which
+isn't part of the tuple. Read the `heading` variable (declared in
+task 1) with `heading get`, add the bearing offset (`ahead = 0`,
+`starboard = 90`, `behind = 180`, `port = 270`), and produce the
+cartesian point. The caller sets `heading` inside a `with-variable`
+block.
 
 ```factor
 0 heading [
@@ -76,8 +82,8 @@ and produces the cartesian point.
 
 ## 4. Flip
 
-Define a generic `flip ( direction -- direction' )` that returns
-the opposite direction.
+Add the methods of the `flip` generic (declared in task 1) so it
+returns the opposite direction.
 
 - For `cardinal`: north ↔ south, east ↔ west.
 - For `polar`: add 180° to the bearing (modulo 360).

exercises/concept/bering-bearings/.meta/design.md

@@ -42,7 +42,13 @@ fudge.
 
 ## Tasks ramp
 
-1. `>cartesian` for `cardinal` — first method. Pure case-lookup.
+1. The data model + `>cartesian` for `cardinal` — define the
+   three direction tuples, the direction symbols, the `heading`
+   variable, and both generics (`>cartesian`, `flip`), then the
+   first method (pure case-lookup). Bundling the declarations
+   here keeps the exercise accretive — the test file references
+   all three tuples and both generics, so they must exist once
+   task 1 is done.
 2. `>cartesian` for `polar` — adds arithmetic, no ambient state.
 3. `>cartesian` for `relative` — adds the dynamic variable.
 4. `flip` — second generic, demonstrates that Factor doesn't

exercises/concept/bering-bearings/bering-bearings/bering-bearings.factor

@@ -1,15 +1,16 @@
 USING: kernel ;
 IN: bering-bearings
 
-! Define your tuples here.
+! Task 1: define the data model and the two generic words here:
+!   - tuple cardinal (slot: direction); tuple polar (magnitude bearing);
+!     tuple relative (distance bearing)
+!   - SYMBOLS: north east south west  ahead starboard behind port
+!   - SYMBOL: heading
+!   - GENERIC: >cartesian ( direction -- x y )
+!   - GENERIC: flip ( direction -- direction' )
+!   - the M: cardinal method of >cartesian
+! The polar/relative >cartesian methods (tasks 2-3) and the flip
+! methods (task 4) are added later.
 
-! Define `heading` as a dynamic variable here.
-
-! Define `>cartesian` as a generic word with one method
-! per direction class.
-
-! Define `flip` as a generic word with one method per
-! direction class.
-
-! Define `add-bearings` here, using TYPED:: to type its
-! cartesian outputs: ( a b -- x: number y: number ).
+: add-bearings ( a b -- x y )
+    "unimplemented" throw ;

exercises/concept/boatswains-bilge/.docs/instructions.md

@@ -62,11 +62,13 @@ throws, the pump is released and the exception propagates.
 
 ## 5. A custom disposable: the valve
 
-Define a brand-new disposable — a `valve` — to round out the
-toolkit.
+Round out the toolkit with a brand-new disposable — a `valve`.
+The tuple is declared for you:
+
+```factor
+TUPLE: valve < disposable is-open ;
+```
 
-- Declare a tuple `valve` that extends `disposable` and adds an
-  `is-open` slot.
 - Define `<valve> ( -- valve )` to construct a fresh valve via
   `new-disposable`, with `is-open` set to `t`.
 - Implement `M: valve dispose*` to flip `is-open` to `f`.

exercises/concept/boatswains-bilge/boatswains-bilge/boatswains-bilge.factor

@@ -13,5 +13,12 @@ IN: boatswains-bilge
 : risky-pump-out ( pump quot -- )
     "unimplemented" throw ;
 
-! Task 5: define `valve` as a custom disposable, `<valve>` as its
-! constructor, and an `M: valve dispose*` method.
+! Task 5: the valve tuple is declared for you. Implement <valve>
+! (construct a fresh open valve) and M: valve dispose* (mark it closed).
+TUPLE: valve < disposable is-open ;
+
+: <valve> ( -- valve )
+    "unimplemented" throw ;
+
+M: valve dispose*
+    "unimplemented" throw ;

exercises/concept/dragons-descendants/.docs/instructions.md

@@ -6,19 +6,27 @@ a name, colour, and age — but specialise in distinctive ways.
 You'll build a small inheritance tree of dragon classes and a
 single word that ages any descendant.
 
-## 1. The base class
+## 1. The dragon family
 
-Define a tuple `dragon` with slots `name`, `color`, `age`, and
-a `<dragon>` constructor.
+Define the whole inheritance tree of tuple classes up front (their
+constructors come in the tasks that follow):
+
+- `dragon` with slots `name`, `color`, `age`.
+- `fire-dragon`, a subclass of `dragon`, adding a `flame-temp` slot.
+- `ice-dragon`, another subclass of `dragon`, adding a `chill-temp`
+  slot.
+- `volcano-dragon`, a subclass of `fire-dragon`, adding a
+  `lava-volume` slot.
+
+Then give `dragon` a `<dragon>` constructor.
 
 ```factor
 "Falkor" "white" 100 <dragon> name>> .   ! => "Falkor"
 ```
 
 ## 2. The fire breathers
 
-Define `fire-dragon` as a subclass of `dragon` with one extra
-slot, `flame-temp`. Give it a `<fire-dragon>` constructor.
+Give `fire-dragon` a `<fire-dragon>` constructor.
 
 ```factor
 "Smaug" "red" 500 1200 <fire-dragon> flame-temp>> .   ! => 1200
@@ -27,8 +35,7 @@ slot, `flame-temp`. Give it a `<fire-dragon>` constructor.
 
 ## 3. The ice breathers
 
-Define `ice-dragon` as another subclass of `dragon`, with one
-extra slot `chill-temp` and a `<ice-dragon>` constructor.
+Give `ice-dragon` a `<ice-dragon>` constructor.
 
 ```factor
 "Frosty" "blue" 200 -40 <ice-dragon> chill-temp>> .   ! => -40
@@ -37,9 +44,7 @@ extra slot `chill-temp` and a `<ice-dragon>` constructor.
 
 ## 4. The volcano dwellers
 
-Define `volcano-dragon` as a subclass of `fire-dragon`, with
-one extra slot `lava-volume` and a `<volcano-dragon>`
-constructor.
+Give `volcano-dragon` a `<volcano-dragon>` constructor.
 
 ```factor
 "Vesuvius" "red" 1000 1500 99 <volcano-dragon> dragon? .       ! => t

exercises/concept/dragons-descendants/.meta/design.md

@@ -46,15 +46,21 @@ the `< disposable` syntax instead of pattern-matching it cold.
 
 ## Tasks ramp
 
-1. **`<dragon>`** — declare the base class with three slots and
-   the `boa` constructor. No inheritance yet.
-2. **`<fire-dragon>`** — first use of `<` — adds one slot. The
-   constructor takes four arguments: three inherited, one new.
-3. **`<ice-dragon>`** — a *sibling* of `fire-dragon`. Reinforces
-   that subclasses of the same parent are disjoint
-   (`ice-dragon?` is `f` for a `fire-dragon`).
-4. **`<volcano-dragon>`** — *grandchild* via `< fire-dragon`.
-   Demonstrates that inheritance is transitive: a
+1. **The dragon family** — declare all four tuple classes up
+   front: the `dragon` base (three slots) and its descendants
+   `fire-dragon` / `ice-dragon` (`< dragon`) and
+   `volcano-dragon` (`< fire-dragon`), then the `<dragon>` `boa`
+   constructor. Bundling the whole hierarchy here keeps the
+   exercise accretive — the test file references every
+   descendant's predicate and accessors, so they must all exist
+   once task 1 is done.
+2. **`<fire-dragon>`** — the first descendant constructor. Takes
+   four arguments: three inherited, one new.
+3. **`<ice-dragon>`** — a *sibling* constructor. Reinforces that
+   subclasses of the same parent are disjoint (`ice-dragon?` is
+   `f` for a `fire-dragon`).
+4. **`<volcano-dragon>`** — a *grandchild* constructor via
+   `< fire-dragon`. Inheritance is transitive: a
    `volcano-dragon` satisfies `dragon?`, `fire-dragon?`, and
    `volcano-dragon?`.
 5. **`age-dragon`** — uses the parent's `change-age` accessor

exercises/concept/dragons-descendants/dragons-descendants/dragons-descendants.factor

@@ -1,17 +1,22 @@
 USING: kernel ;
 IN: dragons-descendants
 
-! Task 1: TUPLE: dragon with slots `name`, `color`, `age`
-!         and a constructor `<dragon> ( name color age -- dragon )`
+! Task 1: define the dragon tuple hierarchy here (dragon and its
+! descendants fire-dragon, ice-dragon, volcano-dragon — see the
+! instructions for each class's slots), then the <dragon> constructor
+! below. The descendant constructors follow in tasks 2-4.
 
-! Task 2: TUPLE: fire-dragon extending dragon, adding `flame-temp`
-!         and `<fire-dragon> ( name color age flame-temp -- fd )`
+: <dragon> ( name color age -- dragon )
+    "unimplemented" throw ;
 
-! Task 3: TUPLE: ice-dragon extending dragon, adding `chill-temp`
-!         and `<ice-dragon> ( name color age chill-temp -- id )`
+: <fire-dragon> ( name color age flame-temp -- fd )
+    "unimplemented" throw ;
 
-! Task 4: TUPLE: volcano-dragon extending fire-dragon, adding `lava-volume`
-!         and `<volcano-dragon> ( name color age flame-temp lava-volume -- vd )`
+: <ice-dragon> ( name color age chill-temp -- id )
+    "unimplemented" throw ;
+
+: <volcano-dragon> ( name color age flame-temp lava-volume -- vd )
+    "unimplemented" throw ;
 
 : age-dragon ( dragon -- )
     "unimplemented" throw ;