Retire Evalutator

Minor rounding bug in eval2

2 files changed, 12 insertions, 10 deletions

diff --git a/docs/roadmap.ja.md b/docs/roadmap.ja.md
index a44afab5..964ff81c 100644
--- a/docs/roadmap.ja.md
+++ b/docs/roadmap.ja.md
@@ -7,7 +7,7 @@
 
 ## 正確性とコンパイル
 
-- 理想 IR の評価器で、狭いフィールドへの Store に必要な切り詰めと丸めを行う。
+- 第25〜27章で、メソッドが狭いフィールドを更新した後に切り詰め前の値を返す問題を修正する。
 - 依存関係全体を調べ、変更を伝播してから保存 IR を再利用する、正しい増分ビルドを実装する。
 - ライブラリオブジェクト全体ではなく、必要なメンバーの IR を選択してロードする。
 - 最適化後の関数サイズと安定した順位を使い、インライン化の選択を決定的にする。
diff --git a/docs/roadmap.md b/docs/roadmap.md
index d441abb9..62c2e509 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -9,11 +9,14 @@ design decisions and chapter boundaries.
 
 ## Correctness
 
-### Narrow stores in the ideal evaluator
+### Narrow field results after method updates
 
-Chapter 23's `Eval2.store` stores the raw value in its Java object array,
-without the truncation performed by a machine Store. This example still
-returns 25710 in the evaluator instead of 110:
+Chapters 25-27 can return an untruncated increment when a method updates a
+narrow field and then reads it. With evaluator stores corrected, this example
+returns 366 instead of 110. Chapter 25's generated RISC-V code also returns
+366: the method's optimized Return uses the raw Add with range `[1-256]`,
+although the Store writes a byte. Chapters 23, 24a/24b, and 28a/28b return 110
+with the corrected evaluator.
 
 ```simple
 struct C { u8 x=255; val next_noInline={ -> x++; return x; }; };
@@ -23,10 +26,9 @@ val b=c.next_noInline();
 return a+10*b+100*c.x;
 ```
 
-Find the earliest affected evaluator, reproduce the failure there, and carry
-the correction through affected snapshots. Check signed fields and floating
-rounding as well as unsigned bytes. Generated code must not be changed to
-match an incorrect evaluator.
+Find where the field read loses its narrowing during parsing or optimization,
+and preserve the converted result independently of the Store. Check both
+signed and unsigned fields and compare ideal evaluation with generated code.
 
 ## Compilation and optimization
 
@@ -282,4 +284,4 @@ Get the Parsers' structure closer to an ideal R-D parser, and matching the
 grammer doc.  Move TYPES to CodeGen, and generally restructure for readability.
 Ponder using try-w-resources to do the keep/unkeep pairing (do NOT do any
 allocation in the `try`, just bring up an object w/auto-closable which tracks
-the unkeeps) - see if that looks any cleaner.
\ No newline at end of file
+the unkeeps) - see if that looks any cleaner.