JIT cond path: keep compare result as b1; br_if accepts b1 or i64 (!=0); add branch_return to benchmark suite.
This commit is contained in:
Moe Charm
@ -0,0 +1,138 @@
|
||||
# ChatGPT5の革命的アイデア - 多言語統合とBox化
|
||||
|
||||
## 元の発想
|
||||
|
||||
ChatGPT5さんの発想は「すべての言語をBoxで包んで統一的に扱う」という革命的なアプローチです。
|
||||
これにより、Python、Rust、JavaScript、Java等の既存エコシステムをNyashから自然に利用できるようになります。
|
||||
|
||||
## 核心概念
|
||||
|
||||
### 1. ForeignBox - 外部リソースのBox化
|
||||
```nyash
|
||||
// 外部言語のオブジェクトをBoxとして扱う
|
||||
box ForeignBox<T> {
|
||||
private { handle } // 外部リソースへのハンドル
|
||||
|
||||
fini() {
|
||||
ny_host_finalizer(me.handle) // 適切にリソース解放
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. ProxyBox - スレッドセーフな委譲
|
||||
```nyash
|
||||
// GILやイベントループを持つ言語用
|
||||
box ProxyBox<T> {
|
||||
private { bus, worker_id } // Bus経由で別スレッドに委譲
|
||||
|
||||
call(method, args) {
|
||||
return me.bus.send_and_wait(me.worker_id, method, args)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 言語別統合戦略（ChatGPT5原案）
|
||||
|
||||
### Python統合
|
||||
- **課題**: GIL（Global Interpreter Lock）
|
||||
- **解決**: ProxyBoxでBus経由ワーカー委譲
|
||||
- **実装**: CPython C-APIで`PyObject*`をForeignBoxに入れる
|
||||
|
||||
### JavaScript/Node.js統合
|
||||
- **課題**: イベントループを壊さない
|
||||
- **解決**: ProxyBox（postMessage/uv_queue_work）
|
||||
- **短い同期関数**: ForeignBoxでも可
|
||||
|
||||
### Rust/C統合
|
||||
- **最短パス**: C-ABI直接
|
||||
- **Rust側**: `#[no_mangle] extern "C"`
|
||||
- **所有権**: Nyash↔Rustのどちらかに寄せる（二重所有禁止）
|
||||
|
||||
### JVM/.NET統合
|
||||
- **方式**: JNI/P-Invoke
|
||||
- **要件**: Pinning必要
|
||||
- **GC連携**: SafeHandle/PhantomReferenceでFinalizer橋渡し
|
||||
|
||||
### WASM統合
|
||||
- **方式**: `ny_host_*`をimport
|
||||
- **データ**: リニアメモリへBytes/Strで搬送
|
||||
|
||||
## 統一インターフェース設計
|
||||
|
||||
### NyIDL（Nyash Interface Definition Language）
|
||||
```idl
|
||||
module ny {
|
||||
box Image;
|
||||
fn load(path: str) -> Image effects = io
|
||||
fn resize(img: Image, w: i32, h: i32) -> Image effects = mut
|
||||
fn width(img: look Image) -> i32 effects = pure
|
||||
}
|
||||
```
|
||||
|
||||
### 自動生成される要素
|
||||
1. Nyash側extern宣言
|
||||
2. C-ABIシム層
|
||||
3. 各言語用スタブ（Rust/Node/Python/JVM）
|
||||
4. ForeignBox/ProxyBoxラッパー
|
||||
|
||||
## 所有権と寿命管理
|
||||
|
||||
### One Strong Owner原則
|
||||
- ForeignBoxは所有者1本（NyashまたはA外部）
|
||||
- 弱参照は`weak/look`で管理
|
||||
- 失効時はnull/false
|
||||
|
||||
### Finalizerの橋渡し
|
||||
1. Nyash `fini` → `ny_host_finalizer`呼び出し
|
||||
2. 外部GC/finalize → `ny_host_finalizer`経由でNyashのweakを失効
|
||||
|
||||
## 効果システムとの統合
|
||||
|
||||
```nyash
|
||||
// 効果注釈でFFI境界の振る舞いを明示
|
||||
extern fn py_numpy_matmul(a: ForeignBox<ndarray>, b: ForeignBox<ndarray>)
|
||||
-> ForeignBox<ndarray> effects mut
|
||||
|
||||
extern fn rust_image_load(path: str)
|
||||
-> ForeignBox<Image> effects io
|
||||
|
||||
extern fn js_fetch(url: str)
|
||||
-> ProxyBox<Promise> effects io
|
||||
```
|
||||
|
||||
## MIRレベルでの統合
|
||||
|
||||
### BoxCall命令の拡張
|
||||
```
|
||||
// 通常のBoxCall
|
||||
BoxCall(%result, %box, "method", [%arg1, %arg2])
|
||||
|
||||
// ForeignBoxのメソッド呼び出し
|
||||
BoxCall(%result, %foreign_box, "py_method", [%arg1])
|
||||
// → 内部でFFI境界を越えて呼び出し
|
||||
|
||||
// ProxyBoxの非同期呼び出し
|
||||
Send(%msg_id, %proxy_box, "method", [%args])
|
||||
Recv(%result, %msg_id)
|
||||
```
|
||||
|
||||
## 革命的な利点
|
||||
|
||||
1. **即座の多言語資産活用**: 既存ライブラリを「箱に詰めて」即Nyashで使える
|
||||
2. **統一的な寿命管理**: 強1＋weak/look＋finiで外部リソースも確定的に回収
|
||||
3. **配布の柔軟性**: WASM/VM/ネイティブのどれでも同じIDLから出荷
|
||||
4. **MIR最適化の恩恵**: 外部言語呼び出しもMIRレベルで最適化可能
|
||||
5. **段階的移行**: 既存プロジェクトを徐々にNyashに移行
|
||||
|
||||
## 実装優先順位
|
||||
|
||||
1. **Phase 1**: C/Rust統合（最も単純）
|
||||
2. **Phase 2**: Python統合（PythonParserBox）
|
||||
3. **Phase 3**: JavaScript/Node.js統合
|
||||
4. **Phase 4**: JVM/.NET統合
|
||||
5. **Phase 5**: 統一IDLと自動生成ツール
|
||||
|
||||
## まとめ
|
||||
|
||||
「すべてをBoxに閉じ込める」という設計を正式化することで、あらゆる言語→NyashとNyash→あらゆる実行系が綺麗に繋がる。
|
||||
これはまさに「Everything is Box」哲学の究極の実現形態といえる。
|
||||
@ -0,0 +1,207 @@
|
||||
# PythonParserBox設計提案 - CPythonパーサーを使ったPython→Nyash変換
|
||||
|
||||
## 概要
|
||||
CPythonの公式パーサーを活用して、PythonコードをNyashで直接実行可能にする革命的なアプローチ。
|
||||
PythonコードをNyashのAST/MIRに変換し、Nyashの最適化・JITコンパイルの恩恵を受けられるようにする。
|
||||
|
||||
## アーキテクチャ
|
||||
|
||||
### 1. PythonParserBox（ビルトインBox）
|
||||
```nyash
|
||||
// 使用例
|
||||
local py_parser = new PythonParserBox()
|
||||
|
||||
// Pythonコードを直接パース
|
||||
local ast = py_parser.parse("""
|
||||
def calculate(x, y):
|
||||
return x * 2 + y
|
||||
|
||||
result = calculate(10, 5)
|
||||
""")
|
||||
|
||||
// NyashのASTに変換
|
||||
local nyash_ast = py_parser.to_nyash_ast(ast)
|
||||
|
||||
// 直接実行も可能
|
||||
local result = py_parser.run(python_code)
|
||||
```
|
||||
|
||||
### 2. 実装構造
|
||||
```rust
|
||||
pub struct PythonParserBox {
|
||||
base: BoxBase,
|
||||
parser: CPythonParser, // CPythonの公式パーサー使用
|
||||
}
|
||||
|
||||
impl PythonParserBox {
|
||||
// Python → Python AST
|
||||
pub fn parse(&self, code: &str) -> Box<dyn NyashBox> {
|
||||
let py_ast = self.parser.parse_string(code);
|
||||
Box::new(PythonAstBox { ast: py_ast })
|
||||
}
|
||||
|
||||
// Python AST → Nyash AST
|
||||
pub fn to_nyash_ast(&self, py_ast: &PythonAstBox) -> Box<dyn NyashBox> {
|
||||
let converter = AstConverter::new();
|
||||
converter.convert_python_to_nyash(py_ast)
|
||||
}
|
||||
|
||||
// Python AST → MIR（直接変換）
|
||||
pub fn to_mir(&self, py_ast: &PythonAstBox) -> MirModule {
|
||||
let mut builder = MirBuilder::new();
|
||||
for func in py_ast.functions() {
|
||||
self.convert_function_to_mir(&mut builder, func);
|
||||
}
|
||||
builder.build()
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## AST変換マッピング
|
||||
|
||||
### Python → Nyash対応表
|
||||
| Python AST | Nyash AST | 説明 |
|
||||
|------------|-----------|------|
|
||||
| FunctionDef | FunctionDecl | 関数定義 |
|
||||
| BinOp | BinaryOp | 二項演算 |
|
||||
| Call | MethodCall | 関数呼び出し |
|
||||
| Assign | Assignment | 代入 |
|
||||
| If | IfStatement | 条件分岐 |
|
||||
| While/For | LoopStatement | ループ |
|
||||
| Return | ReturnStatement | return文 |
|
||||
| Import | NewBox/LoadPlugin | import → Box化 |
|
||||
|
||||
### 型変換戦略
|
||||
```rust
|
||||
// Python動的型 → Nyash Box
|
||||
match py_value {
|
||||
PyInt(n) => IntegerBox::new(n),
|
||||
PyFloat(f) => FloatBox::new(f),
|
||||
PyStr(s) => StringBox::new(s),
|
||||
PyList(items) => ArrayBox::from_iter(items),
|
||||
PyDict(map) => MapBox::from_iter(map),
|
||||
PyObject(obj) => PythonObjectBox::new(obj), // 変換不能な場合
|
||||
}
|
||||
```
|
||||
|
||||
## MIR生成例
|
||||
|
||||
### Pythonコード
|
||||
```python
|
||||
def calculate(x, y):
|
||||
return x * 2 + y
|
||||
```
|
||||
|
||||
### 生成されるMIR
|
||||
```
|
||||
function calculate(%x, %y) {
|
||||
Load(%1, %x)
|
||||
Const(%2, 2)
|
||||
BinOp(%3, Mul, %1, %2)
|
||||
Load(%4, %y)
|
||||
BinOp(%5, Add, %3, %4)
|
||||
Return(%5)
|
||||
}
|
||||
```
|
||||
|
||||
## 利点
|
||||
|
||||
1. **完全な互換性**: CPython公式パーサーで100%正確なパース
|
||||
2. **統一最適化**: PythonコードもNyashのMIR最適化パイプラインを通る
|
||||
3. **JIT/AOTコンパイル**: PythonコードをネイティブコードにJIT/AOTコンパイル可能
|
||||
4. **段階的移行**: 既存Pythonコードを徐々にNyashに移行
|
||||
5. **デバッグ統一**: Nyashのデバッグツールでpythonコードもデバッグ可能
|
||||
|
||||
## 実装フェーズ
|
||||
|
||||
### Phase 1: 基本パーサー統合
|
||||
- CPythonパーサーのFFIバインディング
|
||||
- parse()メソッドでPython ASTを取得
|
||||
- AST可視化（dump_ast）
|
||||
|
||||
### Phase 2: AST変換
|
||||
- Python AST → Nyash AST変換器
|
||||
- 基本的な文法要素のサポート
|
||||
- 型変換システム
|
||||
|
||||
### Phase 3: MIR直接生成
|
||||
- Python AST → MIR変換
|
||||
- Python特有の最適化（動的型推論等）
|
||||
- ベンチマーク
|
||||
|
||||
### Phase 4: エコシステム統合
|
||||
- NumPy等の主要ライブラリサポート
|
||||
- Python例外 → Nyashエラー変換
|
||||
- async/await対応
|
||||
- GIL管理の自動化
|
||||
|
||||
## 技術的課題と解決策
|
||||
|
||||
### 1. GIL（Global Interpreter Lock）
|
||||
- 解決策: PythonコードはGILスコープ内で実行
|
||||
- 将来: MIR変換後はGILフリーで実行可能
|
||||
|
||||
### 2. Python動的型とNyash Box型のマッピング
|
||||
- 解決策: 実行時型情報を保持するPythonObjectBox
|
||||
- 最適化: よく使う型（int, str等）は専用Boxに変換
|
||||
|
||||
### 3. Pythonモジュールシステム
|
||||
- 解決策: importをNyashのプラグインロードにマッピング
|
||||
- pip packages → Nyashプラグインとして扱う
|
||||
|
||||
## 実用例
|
||||
|
||||
### 機械学習コードの実行
|
||||
```nyash
|
||||
local ml_code = """
|
||||
import numpy as np
|
||||
from sklearn.linear_model import LinearRegression
|
||||
|
||||
# データ準備
|
||||
X = np.array([[1, 1], [1, 2], [2, 2], [2, 3]])
|
||||
y = np.dot(X, np.array([1, 2])) + 3
|
||||
|
||||
# モデル訓練
|
||||
model = LinearRegression()
|
||||
model.fit(X, y)
|
||||
|
||||
# 予測
|
||||
predictions = model.predict(np.array([[3, 5]]))
|
||||
print(f'Prediction: {predictions[0]}')
|
||||
"""
|
||||
|
||||
local py_parser = new PythonParserBox()
|
||||
local result = py_parser.run(ml_code)
|
||||
```
|
||||
|
||||
### Webアプリケーション
|
||||
```nyash
|
||||
local flask_app = """
|
||||
from flask import Flask, jsonify
|
||||
|
||||
app = Flask(__name__)
|
||||
|
||||
@app.route('/api/hello/<name>')
|
||||
def hello(name):
|
||||
return jsonify({'message': f'Hello, {name}!'})
|
||||
|
||||
if __name__ == '__main__':
|
||||
app.run(port=5000)
|
||||
"""
|
||||
|
||||
local py_parser = new PythonParserBox()
|
||||
py_parser.run(flask_app) // FlaskアプリがNyash内で起動
|
||||
```
|
||||
|
||||
## 期待される効果
|
||||
|
||||
1. **パフォーマンス向上**: PythonコードがJITコンパイルされ高速化
|
||||
2. **メモリ効率**: NyashのGC/メモリ管理を活用
|
||||
3. **相互運用性**: Python↔Nyash↔Rust↔JS等の自由な組み合わせ
|
||||
4. **開発効率**: 既存Pythonライブラリをそのまま使える
|
||||
5. **将来性**: PythonコードをネイティブAOTコンパイル可能
|
||||
|
||||
## まとめ
|
||||
|
||||
PythonParserBoxは、Pythonの豊富なエコシステムとNyashの高性能実行エンジンを組み合わせる画期的なアプローチ。
|
||||
CPythonパーサーの信頼性とNyashのMIR/JIT最適化により、Pythonコードをより高速に、より効率的に実行できる。
|
||||
@ -0,0 +1,98 @@
|
||||
# 2025-08-27 議論まとめ - PythonParserBoxと言語間統合
|
||||
|
||||
## 本日の議論の流れ
|
||||
|
||||
### 1. ベンチマーク実行と問題発見
|
||||
- インタープリター性能問題（10万回ループで2分以上）
|
||||
- VM変数管理エラー
|
||||
- Box APIの成熟度不足（TimeBox.elapsed()が呼べない）
|
||||
- 問題点をPhase 10ドキュメントに追記
|
||||
|
||||
### 2. Cranelift AOT Backendの追加（Phase 10.9）
|
||||
- JIT実装の基盤を再利用して事前コンパイル可能
|
||||
- 非同期完全サポート（WASMの制限なし）
|
||||
- 実装期間2-3週間で可能（上乗せだけ）
|
||||
|
||||
### 3. PythonParserBox構想の深堀り
|
||||
- ChatGPT5さんの「CPythonをBoxで包みMIRに落とし込む」アイデアを具体化
|
||||
- CPythonの公式パーサーを使ってPythonコード→Nyash AST/MIR変換
|
||||
- ビルトインBoxとして分離実装
|
||||
|
||||
### 4. エキスパートへの相談結果
|
||||
|
||||
#### Gemini先生の分析
|
||||
- pyo3活用で技術的課題は解決可能
|
||||
- 最初は特定ドメインのサブセットから開始すべき
|
||||
- GIL管理のBox隠蔽は現実的
|
||||
- 設計思想は他言語（Ruby/JS）にも応用可能
|
||||
|
||||
#### Codex先生の実装提案
|
||||
- CPython内部APIではなく、安定した`ast`モジュール経由
|
||||
- Python側で`ast.parse()` → JSON → Rust側で処理
|
||||
- 最小実装セット定義（基本構造＋演算＋制御フロー）
|
||||
- 純Pythonループで2-10倍の高速化が現実的
|
||||
|
||||
### 5. Phase 10.1フォルダの作成と整理
|
||||
以下のドキュメントをPhase 10.1に整理：
|
||||
- python_parser_box_design.txt（基本設計）
|
||||
- python_parser_box_implementation_plan.txt（実装計画）
|
||||
- chatgpt5_original_idea.txt（元のアイデア）
|
||||
- summary_2025_08_27.txt（本まとめ）
|
||||
|
||||
## 技術的な要点
|
||||
|
||||
### 実装アプローチ
|
||||
```rust
|
||||
// pyo3でCPythonを埋め込み
|
||||
pyo3 = { version = "0.22", features = ["auto-initialize"] }
|
||||
|
||||
// Python側でAST→JSON変換
|
||||
def parse_to_json(code):
|
||||
tree = ast.parse(code)
|
||||
return json.dumps(ast_to_dict(tree))
|
||||
|
||||
// Rust側で受け取り
|
||||
let json_ast = py_helper.parse_to_json(python_code);
|
||||
let nyash_ast = convert_json_to_nyash_ast(json_ast);
|
||||
```
|
||||
|
||||
### 最小実装セット（Phase 1-2）
|
||||
- 構造: Module, FunctionDef, Return, Assign
|
||||
- 演算: BinOp, Compare, Call, Name, Constant
|
||||
- 制御: If, While, Br, CondBr
|
||||
- 実行: 最初はCPython exec委譲、段階的にMIR実行へ
|
||||
|
||||
### データ共有戦略
|
||||
- NumPy配列: pyo3-numpyでゼロコピー共有
|
||||
- NdArrayBox: Nyash側でNumPy配列を効率的に扱う
|
||||
- バッファプロトコル: PEP 3118で汎用オブジェクト共有
|
||||
|
||||
### 期待される効果
|
||||
- 純Pythonループ: 2-10倍高速化
|
||||
- NumPy処理: 1.0-1.2倍（既に最適化済み）
|
||||
- 将来的: トレースベース最適化で10-30倍も可能
|
||||
|
||||
## 次のステップ
|
||||
|
||||
1. **Phase 1実装開始**（1-2週間）
|
||||
- pyo3統合とPythonParserBox基本実装
|
||||
- parse_to_jsonヘルパー作成
|
||||
- 最小AST変換動作確認
|
||||
|
||||
2. **小規模ベンチマーク**
|
||||
- 簡単なPython関数で動作確認
|
||||
- 性能測定と改善点洗い出し
|
||||
|
||||
3. **段階的拡張**
|
||||
- MIR変換実装
|
||||
- NumPy統合
|
||||
- より複雑なPython機能対応
|
||||
|
||||
## まとめ
|
||||
|
||||
PythonParserBoxは、Nyashの「Everything is Box」哲学を言語間統合に拡張する革命的なアプローチ。
|
||||
CPythonパーサーの信頼性とNyashのMIR/JIT最適化を組み合わせることで、Pythonエコシステムを
|
||||
Nyashから自然に利用でき、かつ高速化も実現できる。
|
||||
|
||||
ChatGPT5さんの最初のアイデア（ForeignBox/ProxyBox）を基に、具体的な実装計画まで落とし込めた。
|
||||
技術的にも実現可能で、段階的なアプローチにより着実に実装できる見込み。
|
||||
@ -0,0 +1,197 @@
|
||||
# PythonParserBox実装計画 - エキスパートフィードバック
|
||||
日付: 2025-08-27
|
||||
|
||||
## Gemini先生のフィードバック
|
||||
|
||||
### 総評
|
||||
これは非常に野心的で、言語の成熟度を飛躍的に高める可能性を秘めた素晴らしい計画です。Nyashの「Everything is a Box」哲学とPythonエコシステムを融合させるという着眼点に大変興奮しました。
|
||||
|
||||
### 1. 実装計画は技術的に健全か？落とし穴は？
|
||||
|
||||
**技術的健全性:**
|
||||
はい、計画は全体として技術的に非常に健全です。
|
||||
|
||||
* **CPythonパーサーの利用:** `pyo3`経由で`ast.parse()`を利用するのは、Python構文との互換性を100%保証するための最も確実で賢明なアプローチです。
|
||||
* **JSON中間表現(IR):** Python AST (Pythonメモリ空間) と Nyash AST (Rustメモリ空間) の間にJSONを挟むのは、言語間の境界を明確に分離する良い設計です。
|
||||
* **段階的実装とフォールバック:** 未実装機能を`exec()`にフォールバックする戦略は、実用性を保ちながら段階的に実装を進めるための極めて現実的なアプローチです。
|
||||
|
||||
**潜在的な落とし穴:**
|
||||
* **パフォーマンス:** `Python AST → JSON → Nyash AST → Nyash実行`というパイプラインは、特に初期段階では非常に低速になります。
|
||||
* **ASTの複雑性の爆発:** PythonのASTは非常に巨大で、言語バージョンの更新も速いです。
|
||||
* **標準ライブラリの壁:** Pythonの真の力は広範な標準/サードパーティライブラリにあります。`import`文をどう扱うかは最重要課題です。
|
||||
|
||||
### 2. Python AST → Nyash AST変換で注意すべき意味論の違いは？
|
||||
|
||||
* **型システム:** Pythonは動的型付け、Nyashは静的型付けまたはより厳格な型システムを持つと推測
|
||||
* **オブジェクトモデルと可変性:** Pythonのオブジェクトは基本的に可変（mutable）
|
||||
* **スコープとクロージャ:** Pythonの`global`や`nonlocal`の挙動は独特
|
||||
* **特殊メソッド (`__dunder__`):** Pythonの挙動は特殊メソッドで定義される
|
||||
* **組み込み関数:** `len()`, `print()`, `range()`などをどう扱うか
|
||||
|
||||
### 3. Nyashパーサーのバグ検証戦略として効果的か？
|
||||
|
||||
**非常に効果的です。** これは「Differential Testing（差分テスト）」と呼ばれる強力な手法です。
|
||||
* **巨大なテストスイート:** 事実上、世の中にある無数のPythonコードがNyashのテストケースになります。
|
||||
* **微妙なバグの発見:** 手書きの単体テストでは見逃しがちなセマンティクスのバグを発見するのに絶大な効果を発揮します。
|
||||
|
||||
### 4. pyo3統合でのGIL管理のベストプラクティスは？
|
||||
|
||||
* **基本原則:** Pythonオブジェクトに触れるコードは、必ずGILを獲得した状態で実行
|
||||
* **GILの必要期間を最小化する**
|
||||
* **`py.allow_threads`の活用:** 時間がかかり、かつPythonオブジェクトに触れない処理で使用
|
||||
|
||||
### 5. 段階的実装（Phase 1-4）の優先順位は適切か？
|
||||
|
||||
はい、提案されている優先順位は非常に適切です。
|
||||
1. Phase 1: 基本構文 + 変数束縛 + 基本的な式 + プリミティブ型
|
||||
2. Phase 2: list, dict, tuple
|
||||
3. Phase 3: 関数とスコープ
|
||||
4. Phase 4: モジュールとクラス
|
||||
|
||||
**最優先で並行すべきこと:** `exec()`へのフォールバック機構
|
||||
|
||||
### 6. 言語成熟度向上への貢献度をどう評価する？
|
||||
|
||||
**定量的指標:**
|
||||
* ライブラリ互換性カバレッジ
|
||||
* パフォーマンステスト
|
||||
* 発見バグ数
|
||||
|
||||
**定性的指標:**
|
||||
* 表現力の向上
|
||||
* 開発者体験
|
||||
* エコシステムのマイルストーン
|
||||
|
||||
### 結論
|
||||
|
||||
この`PythonParserBox`計画は、単なる機能追加ではなく、**Nyash言語のテスト、デバッグ、そしてエコシステム獲得を同時に加速させる、極めて戦略的な一手**です。
|
||||
|
||||
---
|
||||
|
||||
## Codex先生のフィードバック
|
||||
|
||||
### Overall Verdict
|
||||
- Sound approach: Using CPython's parser via pyo3, lowering via a JSON IR, and gradually replacing exec() with Nyash MIR/JIT is feasible and strategically strong.
|
||||
- Biggest risks: Semantic mismatches at statement/expression boundaries, version skew of Python AST, and boundary-costs between CPython and Nyash during phased rollout.
|
||||
|
||||
### Architectural Pitfalls
|
||||
- **Python version skew:** `ast` schema changes across minors. Pin and encode `py_version` + `ast_format` in the JSON.
|
||||
- **AST stability vs syntax fidelity:** `ast` loses comments and some token distinctions
|
||||
- **Boundary granularity:** Whole-file fallback wastes partial coverage; per-node fallback is unsafe. **The practical unit is per-function.**
|
||||
- **Import system and environment:** Python imports pull arbitrary code
|
||||
- **Error mapping:** Propagate Python exceptions with full traceback
|
||||
- **Performance overhead:** Python AST→JSON→Nyash→MIR is heavy
|
||||
- **Object model mismatch:** Identity (`is`), mutability, truthiness, numeric tower
|
||||
- **Concurrency:** GIL limits parallel parse/exec
|
||||
|
||||
### AST→Nyash Semantics: High-Risk Differences
|
||||
- **Names and scope:**
|
||||
- LEGB resolution; `global`/`nonlocal` behavior; closures and cell variables
|
||||
- Comprehension scopes (separate scope in Python 3)
|
||||
- **Control flow:**
|
||||
- `for` iterates via iterator protocol; `for/else`, `while/else` semantics
|
||||
- Short-circuit truthiness uses Python rules; `__bool__` then `__len__`
|
||||
- **Functions:**
|
||||
- Defaults evaluated at definition time; `*args/**kwargs`
|
||||
- Decorators transform functions at definition time
|
||||
- **Operators and numbers:**
|
||||
- `/` true division; `//` floor division; big integers by default
|
||||
- Operator dispatch via dunder methods; `is` vs `==`
|
||||
|
||||
For Phase 1, the must-haves are: LEGB + locals/freevars, default args timing, iterator-based `for`, `for/else` + `while/else`, Python truthiness and short-circuiting.
|
||||
|
||||
### Fallback Strategy
|
||||
- **Fallback unit: Per-function.** If a function body contains unsupported nodes, compile a "PyThunk" that calls into CPython.
|
||||
- **Boundary types:** Define canonical bridges: `PyAnyBox` in Nyash wrapping `Py<PyAny>`
|
||||
- **Imports and globals:** Execute module top-level in Python; then selectively replace functions
|
||||
|
||||
### pyo3/GIL Best Practices
|
||||
- **Initialization:** Call `pyo3::prepare_freethreaded_python()` once
|
||||
- **GIL usage:**
|
||||
- Use `Python::with_gil(|py| { ... })` for all Python calls
|
||||
- Minimize time under GIL; copy data out promptly
|
||||
- For heavy Rust work, drop GIL: `py.allow_threads(|| { ... })`
|
||||
- **Data transfer:** Prefer building JSON on the Python side
|
||||
- **Versioning:** Pin Python minor version; embed version string in the IR
|
||||
|
||||
### Phasing and Priorities (Refined)
|
||||
- **Phase 1 (Parser + Minimal Semantics):**
|
||||
- Python→JSON exporter with location info
|
||||
- Nyash IR for expressions and basic statements
|
||||
- Semantics fidelity for: iterator protocol, truthiness, scoping
|
||||
- **Fallback per-function for anything else**
|
||||
- **Phase 2-4:** Coverage expansion → Objects/Runtime → MIR/JIT
|
||||
|
||||
### Parser Bug Validation Strategy
|
||||
- **Differential execution:** Curate pairs of semantically equivalent snippets
|
||||
- **Oracle testing:** Run CPython as oracle and compare
|
||||
- **Fuzzing:** Grammar-based fuzzers
|
||||
- **Coverage and gating:** Track node-kind coverage
|
||||
|
||||
### IR/JSON Design Tips
|
||||
- Include: `node_type`, children, `lineno/col_offset`, `py_version`, `ast_format`, `support_level`
|
||||
- Canonicalize: normalize forms, operator names
|
||||
- Determinism: maintain stable field ordering
|
||||
|
||||
### Concrete Recommendations
|
||||
- **Pin to one Python minor (e.g., 3.11 or 3.12)**
|
||||
- **Choose per-function fallback as the core boundary**
|
||||
- **Implement Python truthiness, iterator protocol, and scoping correctly before optimizing**
|
||||
- **Keep the GIL minimal: build the JSON in Python; parse in Rust**
|
||||
- **Telemetry from day one: log unsupported node kinds and fallback counts**
|
||||
- **Start with JSON; plan migration to a compact binary once stable**
|
||||
|
||||
---
|
||||
|
||||
## 統合された重要ポイント
|
||||
|
||||
### 🎯 両エキスパートが一致した最重要事項
|
||||
|
||||
1. **関数単位のフォールバック戦略**
|
||||
- ファイル全体でなく関数レベルでコンパイル/フォールバックを切り替え
|
||||
- 未対応機能を含む関数はCPython exec、対応済み関数はNyash MIR/JIT
|
||||
|
||||
2. **Python バージョン固定**
|
||||
- Python 3.11または3.12に固定
|
||||
- AST安定性の確保とバージョン間の差異回避
|
||||
|
||||
3. **意味論の正確な実装が最優先**
|
||||
- 最適化より先にPython互換性を確保
|
||||
- 特に: イテレータプロトコル、真偽値判定、スコーピング規則
|
||||
|
||||
4. **GIL管理の最小化**
|
||||
- Python側でJSON生成、Rust側で解析
|
||||
- 重い処理はGIL外で実行
|
||||
|
||||
5. **テレメトリーの重要性**
|
||||
- 未対応ノードの記録
|
||||
- フォールバック率の計測
|
||||
- 実行時の統計情報収集
|
||||
|
||||
### 🚨 特に注意すべき意味論の違い
|
||||
|
||||
1. **制御フロー**
|
||||
- for/else, while/else の独特な挙動
|
||||
- forループのイテレータプロトコル
|
||||
|
||||
2. **スコープ規則**
|
||||
- LEGB（Local, Enclosing, Global, Builtins）
|
||||
- global/nonlocal宣言
|
||||
- 内包表記の独立スコープ（Python 3）
|
||||
|
||||
3. **数値演算**
|
||||
- / (true division) vs // (floor division)
|
||||
- デフォルトで大整数
|
||||
- NaN の扱い
|
||||
|
||||
4. **関数定義**
|
||||
- デフォルト引数は定義時に評価
|
||||
- *args/**kwargs の扱い
|
||||
- デコレータの実行順序
|
||||
|
||||
### 📊 成功の測定指標
|
||||
|
||||
1. **カバレッジ**: コンパイル済み vs フォールバック関数の比率
|
||||
2. **性能向上**: 数値計算ベンチマークでの改善率
|
||||
3. **バグ発見数**: Differential Testingで発見されたバグ数
|
||||
4. **エコシステム**: 動作する有名Pythonライブラリの数
|
||||
@ -0,0 +1,148 @@
|
||||
# PythonParserBox統合実装計画 - エキスパート評価後の最終版
|
||||
作成日: 2025-08-27
|
||||
|
||||
## 🎯 革命的な3つの価値
|
||||
|
||||
### 1. Pythonエコシステムの即座活用
|
||||
- 既存のPythonライブラリをNyashから直接利用可能
|
||||
- 段階的な移行パスの提供
|
||||
|
||||
### 2. Nyashパーサーのバグ自動検証（Differential Testing）
|
||||
- **世界中のPythonコードがNyashのテストケースに！**
|
||||
- CPythonをオラクルとして使用、出力・戻り値・例外を自動比較
|
||||
- 微妙なセマンティクスバグを大量に発見可能
|
||||
|
||||
### 3. 言語成熟度の飛躍的向上
|
||||
- 実用的なPythonコードでNyashをストレステスト
|
||||
- 発見されたバグ数が成熟度向上の定量的指標
|
||||
|
||||
## 🏆 エキスパート評価サマリー
|
||||
|
||||
### Gemini先生の評価
|
||||
**「非常に野心的で、言語の成熟度を飛躍的に高める可能性を秘めた素晴らしい計画」**
|
||||
|
||||
- 技術的に健全なアプローチ
|
||||
- pyo3経由のCPythonパーサー利用は最も確実
|
||||
- Differential Testingは極めて強力な手法
|
||||
|
||||
### Codex先生の評価
|
||||
**「Sound approach with strategic strength」**
|
||||
|
||||
- 関数単位フォールバックが実用的かつ効果的
|
||||
- Python 3.11固定でAST安定性確保
|
||||
- テレメトリー重視で継続的改善可能
|
||||
|
||||
## 🔑 統合された5つの核心戦略
|
||||
|
||||
### 1. 関数単位フォールバック（両エキスパート一致）
|
||||
```python
|
||||
def supported_function(): # → Nyash MIR/JIT
|
||||
return x + y
|
||||
|
||||
def unsupported_function(): # → CPython exec
|
||||
yield from generator # Phase 1では未対応
|
||||
```
|
||||
|
||||
### 2. Python 3.11固定
|
||||
- AST安定性確保（3.8 Constant統一、3.10 match/case、3.12位置情報）
|
||||
- `py_version`と`ast_format`をJSON IRに埋め込む
|
||||
|
||||
### 3. 意味論の正確な実装優先
|
||||
Phase 1必須要素（Codex先生強調）：
|
||||
- LEGB + locals/freevars（スコーピング）
|
||||
- デフォルト引数の評価タイミング（定義時）
|
||||
- イテレータベースのfor文
|
||||
- for/else + while/else（Python独特）
|
||||
- Python真偽値判定（`__bool__` → `__len__`）
|
||||
- 短絡評価（and/or）
|
||||
|
||||
### 4. GIL管理の最小化
|
||||
```rust
|
||||
// GILは最小限に！
|
||||
let json_ast = Python::with_gil(|py| {
|
||||
py_helper.parse_to_json(py, code) // Python側でJSON生成
|
||||
})?;
|
||||
|
||||
// GIL外でRust処理
|
||||
let nyash_ast = py.allow_threads(|| {
|
||||
convert_json_to_nyash(json_ast)
|
||||
});
|
||||
```
|
||||
|
||||
### 5. テレメトリー基盤
|
||||
```bash
|
||||
[PythonParser] Module: example.py (Python 3.11)
|
||||
Functions: 10 total
|
||||
Compiled: 7 (70%)
|
||||
Fallback: 3 (30%)
|
||||
- async_function: unsupported node 'AsyncFunctionDef' at line 23
|
||||
```
|
||||
|
||||
## 📋 実装フェーズ（詳細版）
|
||||
|
||||
### Phase 0: 準備（1週間）
|
||||
- [ ] Python 3.11.9環境固定
|
||||
- [ ] テレメトリー基盤構築
|
||||
- [ ] Differential Testingフレームワーク
|
||||
- [ ] JSON IR仕様策定
|
||||
|
||||
### Phase 1: Core Subset（2週間）
|
||||
- [ ] pyo3統合（prepare_freethreaded_python）
|
||||
- [ ] 関数単位コンパイル判定器
|
||||
- [ ] 基本構文（def/if/for/while/return）
|
||||
- [ ] 意味論必須要素の実装
|
||||
- [ ] CPythonとの出力比較テスト
|
||||
|
||||
### Phase 2: Data Model（3週間）
|
||||
- [ ] 特殊メソッドマッピング
|
||||
- [ ] list/dict/tuple実装
|
||||
- [ ] 演算子オーバーロード
|
||||
|
||||
### Phase 3: Advanced Features（1ヶ月）
|
||||
- [ ] 例外処理（try/except）
|
||||
- [ ] with文、ジェネレータ
|
||||
- [ ] 内包表記、デコレータ
|
||||
|
||||
## 📊 成功の測定基準
|
||||
|
||||
### 定量的指標
|
||||
| 指標 | 目標 | 測定方法 |
|
||||
|------|------|----------|
|
||||
| カバレッジ率 | 70%以上 | コンパイル済み vs フォールバック関数 |
|
||||
| 性能向上 | 2-10倍 | 純Pythonループのベンチマーク |
|
||||
| バグ発見数 | 10+件/Phase | Differential Testing |
|
||||
| エコシステム | 1以上 | 動作する有名ライブラリ数 |
|
||||
|
||||
### マイルストーン
|
||||
- Phase 1: "Hello from Python in Nyash"が動作
|
||||
- Phase 2: scikit-learnの基本アルゴリズムが動作
|
||||
- Phase 3: FlaskのHello Worldが動作
|
||||
- Phase 4: PyPIトップ100の30%が基本動作
|
||||
|
||||
## 🚨 注意すべき意味論の違い（トップ5）
|
||||
|
||||
1. **制御フロー**: for/else, while/else
|
||||
2. **スコープ規則**: LEGB、global/nonlocal
|
||||
3. **数値演算**: / (true division) vs //
|
||||
4. **関数定義**: デフォルト引数は定義時評価
|
||||
5. **真偽値判定**: Pythonの__bool__/__len__ルール
|
||||
|
||||
## 🎉 期待されるインパクト
|
||||
|
||||
### 技術的成果
|
||||
- Pythonエコシステムの活用
|
||||
- Nyashパーサーの品質向上
|
||||
- 性能最適化の実証
|
||||
|
||||
### 戦略的価値
|
||||
- 言語成熟度の飛躍的向上
|
||||
- 開発者コミュニティの拡大
|
||||
- 実用アプリケーション開発の加速
|
||||
|
||||
## 📝 結論
|
||||
|
||||
PythonParserBoxは、単なる機能追加ではなく、**Nyash言語のテスト、デバッグ、エコシステム獲得を同時に加速させる極めて戦略的なプロジェクト**。
|
||||
|
||||
両エキスパートの技術的評価と具体的な実装指針により、実現可能性が確認され、明確な実装パスが定まった。
|
||||
|
||||
**「Everything is Box」哲学を、言語の壁を超えて実現する革命的な一歩。**
|
||||
Reference in New Issue
Block a user