refactor: eliminate decreasing_by in Parser.lean in favour of structural recursion
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 42/100
- issue の種類
- リファクタリング
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 領域
- compilers
調査の方向性
Lck/Regex/Parser.lean を開き、646 行目と 912 行目のパース処理コードを調べてから、CLAUDE.md の停止性に関するガイダンスを読んでください。影響を受ける再帰呼び出しで、構造的により小さいトークンリストを使用できるか判断してください。両方の decreasing_by の使用箇所を削除するか、再構成が実行不可能な理由を説明するコメントを記述すれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Problem
Lck/Regex/Parser.lean at lines 646 and 912 uses decreasing_by to convince the termination checker. Per CLAUDE.md, decreasing_by is a code smell for parsers — a well-structured LL(1) parser over a token list should terminate structurally.
Expected fix
Restructure the affected parsing functions so that recursive calls are made on a syntactically smaller token list, allowing the Lean termination checker to accept them without decreasing_by. If this turns out to be infeasible, document why with a comment.
References
- Observed by AI code review on PR #9
- See CLAUDE.md termination discipline
- 主要言語
- Lean
- スター
- 2
- フォーク
- 1
- PR マージ指標
- 30日以内にマージされた PR はありません
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
lambdaclass/lambda_compiler_kit のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 68/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
enhancement
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 50/100
lambdaclass/lambda_compiler_kit の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
objectionary/eo#8923 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
Coarray integration tests carry no LABELS, so run_tests.py silently skips them under every backend オープンcoarray
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
internal.h中，漏掉了1个定义。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 95/100