refactor(llvm): Complete Call instruction modularization + Phase 21 organization
## LLVM Call Instruction Modularization - Moved MirInstruction::Call lowering to separate instructions/call.rs - Follows the principle of one MIR instruction per file - Call implementation was already complete, just needed modularization ## Phase 21 Documentation - Moved all Phase 21 content to private/papers/paper-f-self-parsing-db/ - Preserved AI evaluations from Gemini and Codex - Academic paper potential confirmed by both AIs - Self-parsing AST database approach validated ## Next Steps - Continue monitoring ChatGPT5's LLVM improvements - Consider creating separate nyash-llvm-compiler crate when LLVM layer is stable - This will reduce build times by isolating LLVM dependencies 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Selfhosting Dev
@ -5,6 +5,7 @@ Summary
|
||||
- Keep fallbacks minimal; fix MIR annotations first.
|
||||
- ExternCall(console/debug) auto‑selects ptr/handle by IR type.
|
||||
- StringBox NewBox i8* fast path; print/log choose automatically.
|
||||
- Implement multi-function lowering and Call lowering for MIR14.
|
||||
|
||||
Done (today)
|
||||
- BoxCall legacy block removed in LLVM codegen; delegation only.
|
||||
@ -17,6 +18,10 @@ Done (today)
|
||||
- ExternCall micro‑split 完了: `externcall.rs` を `externcall/` ディレクトリ配下に分割し、
|
||||
`console.rs`（console/debug）と `env.rs`（future/local/box）に切り出し。
|
||||
ディスパッチは `externcall/mod.rs` に集約（挙動差分なし・0‑diff）。
|
||||
- String Fast‑Path 追加（LLVM/NYRT）: `substring(start,end)` と `lastIndexOf(needle)` を実装。
|
||||
- Compare: String/StringBox 注釈のときは内容比較（`nyash.string.eq_hh`）にブリッジ。
|
||||
- LLVM 多関数 Lower の骨格を実装: 全関数を事前宣言→順次Lower→`ny_main` ラッパで呼び出し正規化。
|
||||
- Call Lowering 追加（MIR14の `MirInstruction::Call`）: callee 文字列定数を解決し、対応するLLVM関数を呼び出し（引数束縛・戻り値格納）。
|
||||
|
||||
Refactor — LLVM codegen instructions modularized (done)
|
||||
- Goal achieved: `instructions.rs` を段階分割し、責務ごとに再配置（0‑diff）。
|
||||
@ -33,8 +38,10 @@ Refactor — LLVM codegen instructions modularized (done)
|
||||
- Wiring: `instructions/mod.rs` が `pub(super) use ...` で再エクスポート。可視性は `pub(in super::super)`/`pub(super)` を維持。
|
||||
- Build: `cargo build --features llvm` グリーン、挙動差分なし。
|
||||
|
||||
Next (optional, small splits)
|
||||
- ExternCall micro‑split（完了）
|
||||
Next (short, focused)
|
||||
- Call Lowering の分離（完了）: `instructions/call.rs` に分割し、`mod.rs` から委譲。
|
||||
- 多関数 Lower 検証: selfhost minimal（dep_tree_min_string）を LLVM で通す（必要なら型注釈の微調整）。
|
||||
- Map コア専用エントリ化（env.box.new 特例整理）と代表スモークの常時化（CI）
|
||||
- types.rs の将来分割（任意）:
|
||||
- `types/convert.rs`（i64<->ptr, f64→box）, `types/classify.rs`, `types/map_types.rs`
|
||||
- 機能拡張（任意・別タスク）:
|
||||
|
||||
42
docs/private/papers/paper-f-self-parsing-db/README.md
Normal file
42
docs/private/papers/paper-f-self-parsing-db/README.md
Normal file
@ -0,0 +1,42 @@
|
||||
# Paper F: Self-Parsing AST Database-Driven Development
|
||||
|
||||
## 論文タイトル案
|
||||
**日本語**: Nyash言語における自己解析ASTデータベース駆動開発 - 極端な単純性が可能にするコード管理パラダイムの革新
|
||||
**英語**: Self-Parsing AST Database-Driven Development in Nyash - Revolutionary Code Management Paradigm Enabled by Extreme Simplicity
|
||||
|
||||
## 概要
|
||||
Phase 21として構想された「自己解析AST×DB駆動開発」アプローチの学術的研究。
|
||||
Nyashの極端な言語シンプルさと自己解析能力を活用し、ソースコードをデータベースで管理する新しい開発パラダイムを提案する。
|
||||
|
||||
## 研究の新規性
|
||||
1. **自己完結型アーキテクチャ**: 外部パーサー不要の自己解析
|
||||
2. **Code as Database**: ソースコード表現の新しい標準モデル
|
||||
3. **柔軟な利用モード**: Git互換性を保ちつつDB利点を享受
|
||||
|
||||
## AI評価
|
||||
- **Gemini**: 学術論文として十分に成立する可能性
|
||||
- **Codex**: 新規性中〜高、レンズ理論の適用など理論的基礎も充実
|
||||
|
||||
## 関連ドキュメント
|
||||
- [初期構想（データベース駆動開発）](README_original.md)
|
||||
- [技術的考慮事項](technical-considerations.md)
|
||||
- [可逆変換アプローチ](reversible-conversion.md)
|
||||
- [箱データベース構想v2](README_v2.md)
|
||||
- [自己解析アプローチ](self-parsing-approach.md)
|
||||
- [AI評価フォルダ](ai-evaluation/)
|
||||
|
||||
## 投稿候補
|
||||
- OOPSLA (Object-Oriented Programming, Systems, Languages & Applications)
|
||||
- ECOOP (European Conference on Object-Oriented Programming)
|
||||
- PLDI (Programming Language Design and Implementation)
|
||||
- ICSE (International Conference on Software Engineering)
|
||||
|
||||
## 論文執筆状況
|
||||
- [ ] アブストラクト作成
|
||||
- [ ] 関連研究調査（Roslyn, Eclipse JDT, LSP, CodeQL等）
|
||||
- [ ] 実装・評価
|
||||
- [ ] 論文本体執筆
|
||||
|
||||
---
|
||||
Created: 2025-09-11
|
||||
Status: 構想段階（AI評価完了）
|
||||
407
docs/private/papers/paper-f-self-parsing-db/README_original.md
Normal file
407
docs/private/papers/paper-f-self-parsing-db/README_original.md
Normal file
@ -0,0 +1,407 @@
|
||||
# Phase 21: データベース駆動開発（DDD: Database-Driven Development）
|
||||
|
||||
## 📋 概要
|
||||
|
||||
ソースコードをファイルではなくデータベースで管理する革命的開発パラダイム。
|
||||
Box、メソッド、名前空間を構造化データとして扱い、リファクタリングを瞬時に完了させる。
|
||||
**「ファイルは1970年代の遺物。21世紀のコードは構造化データベースに住む」**
|
||||
|
||||
## 🎯 背景と動機
|
||||
|
||||
### 現状の問題
|
||||
- **ファイルベース**：物理的な区切り（人間の都合）
|
||||
- **Box/メソッド**：論理的な単位（プログラムの本質）
|
||||
- **不一致の結果**：リファクタリングが遅い、検索が非効率、依存関係が不透明
|
||||
|
||||
### 解決策
|
||||
- コードをSQLiteデータベースで管理
|
||||
- Box、メソッド、依存関係を正規化されたテーブルで表現
|
||||
- SQLクエリでリファクタリング・検索・分析を高速化
|
||||
|
||||
## 🏗️ データベーススキーマ
|
||||
|
||||
### 基本テーブル構造
|
||||
|
||||
```sql
|
||||
-- Boxの定義
|
||||
CREATE TABLE boxes (
|
||||
id INTEGER PRIMARY KEY,
|
||||
name TEXT NOT NULL,
|
||||
namespace TEXT,
|
||||
parent_box_id INTEGER,
|
||||
box_type TEXT CHECK(box_type IN ('normal', 'static', 'abstract')),
|
||||
source_code TEXT,
|
||||
metadata JSON, -- 型情報、アノテーション、ドキュメント
|
||||
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||||
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||||
FOREIGN KEY (parent_box_id) REFERENCES boxes(id)
|
||||
);
|
||||
|
||||
-- メソッド定義
|
||||
CREATE TABLE methods (
|
||||
id INTEGER PRIMARY KEY,
|
||||
box_id INTEGER NOT NULL,
|
||||
name TEXT NOT NULL,
|
||||
visibility TEXT CHECK(visibility IN ('public', 'private', 'protected')),
|
||||
params JSON, -- パラメータ情報
|
||||
return_type JSON,
|
||||
body TEXT,
|
||||
mir_cache BLOB, -- コンパイル済みMIRをキャッシュ
|
||||
optimization_hints JSON,
|
||||
FOREIGN KEY (box_id) REFERENCES boxes(id),
|
||||
UNIQUE(box_id, name) -- 同一Box内でメソッド名は一意
|
||||
);
|
||||
|
||||
-- フィールド定義
|
||||
CREATE TABLE fields (
|
||||
id INTEGER PRIMARY KEY,
|
||||
box_id INTEGER NOT NULL,
|
||||
name TEXT NOT NULL,
|
||||
field_type JSON,
|
||||
default_value TEXT,
|
||||
metadata JSON,
|
||||
FOREIGN KEY (box_id) REFERENCES boxes(id)
|
||||
);
|
||||
|
||||
-- 依存関係
|
||||
CREATE TABLE dependencies (
|
||||
from_type TEXT CHECK(from_type IN ('box', 'method')),
|
||||
from_id INTEGER,
|
||||
to_type TEXT CHECK(to_type IN ('box', 'method')),
|
||||
to_id INTEGER,
|
||||
dep_type TEXT CHECK(dep_type IN ('uses', 'extends', 'calls', 'implements')),
|
||||
metadata JSON, -- 呼び出し位置、使用頻度など
|
||||
PRIMARY KEY (from_type, from_id, to_type, to_id, dep_type)
|
||||
);
|
||||
|
||||
-- 名前空間
|
||||
CREATE TABLE namespaces (
|
||||
id INTEGER PRIMARY KEY,
|
||||
path TEXT UNIQUE NOT NULL,
|
||||
parent_id INTEGER,
|
||||
metadata JSON,
|
||||
FOREIGN KEY (parent_id) REFERENCES namespaces(id)
|
||||
);
|
||||
|
||||
-- コンパイルキャッシュ
|
||||
CREATE TABLE compile_cache (
|
||||
id INTEGER PRIMARY KEY,
|
||||
entity_type TEXT,
|
||||
entity_id INTEGER,
|
||||
mir_version INTEGER,
|
||||
mir_data BLOB,
|
||||
metadata JSON, -- 最適化レベル、ターゲットなど
|
||||
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
|
||||
);
|
||||
|
||||
-- 全文検索用インデックス
|
||||
CREATE VIRTUAL TABLE code_search USING fts5(
|
||||
entity_type,
|
||||
entity_id,
|
||||
name,
|
||||
content,
|
||||
tokenize = 'porter'
|
||||
);
|
||||
```
|
||||
|
||||
## 🚀 革命的な機能
|
||||
|
||||
### 1. 瞬間リファクタリング
|
||||
|
||||
```sql
|
||||
-- 名前変更：トランザクション一発
|
||||
BEGIN TRANSACTION;
|
||||
UPDATE boxes SET name = 'NewBoxName' WHERE name = 'OldBoxName';
|
||||
UPDATE code_search SET name = 'NewBoxName'
|
||||
WHERE entity_type = 'box' AND name = 'OldBoxName';
|
||||
-- 依存コードも自動更新（トリガーで実装）
|
||||
COMMIT;
|
||||
|
||||
-- メソッド移動：Box間でメソッドを移動
|
||||
UPDATE methods SET box_id = (SELECT id FROM boxes WHERE name = 'TargetBox')
|
||||
WHERE id = ? AND box_id = ?;
|
||||
```
|
||||
|
||||
### 2. 高度な検索・分析
|
||||
|
||||
```sql
|
||||
-- 未使用コード検出
|
||||
SELECT b.namespace || '.' || b.name AS unused_box
|
||||
FROM boxes b
|
||||
LEFT JOIN dependencies d ON
|
||||
(d.to_type = 'box' AND d.to_id = b.id)
|
||||
WHERE d.from_id IS NULL;
|
||||
|
||||
-- 循環依存検出（再帰CTE）
|
||||
WITH RECURSIVE dep_path AS (
|
||||
SELECT from_id, to_id,
|
||||
from_id || '->' || to_id as path
|
||||
FROM dependencies
|
||||
WHERE from_type = 'box' AND to_type = 'box'
|
||||
UNION ALL
|
||||
SELECT d.from_id, dp.to_id,
|
||||
dp.path || '->' || d.to_id
|
||||
FROM dependencies d
|
||||
JOIN dep_path dp ON d.to_id = dp.from_id
|
||||
WHERE d.from_type = 'box' AND d.to_type = 'box'
|
||||
AND dp.path NOT LIKE '%' || d.to_id || '%'
|
||||
)
|
||||
SELECT path FROM dep_path WHERE from_id = to_id;
|
||||
|
||||
-- 類似コード検出（全文検索）
|
||||
SELECT b1.name AS box1, m1.name AS method1,
|
||||
b2.name AS box2, m2.name AS method2,
|
||||
similarity_score(m1.body, m2.body) AS similarity
|
||||
FROM methods m1
|
||||
JOIN methods m2 ON m1.id < m2.id
|
||||
JOIN boxes b1 ON m1.box_id = b1.id
|
||||
JOIN boxes b2 ON m2.box_id = b2.id
|
||||
WHERE similarity_score(m1.body, m2.body) > 0.8;
|
||||
```
|
||||
|
||||
### 3. インテリジェントなキャッシング
|
||||
|
||||
```sql
|
||||
-- 変更影響分析
|
||||
CREATE TRIGGER invalidate_cache_on_method_update
|
||||
AFTER UPDATE ON methods
|
||||
BEGIN
|
||||
-- 直接依存するエンティティのキャッシュを無効化
|
||||
DELETE FROM compile_cache
|
||||
WHERE entity_id IN (
|
||||
SELECT from_id FROM dependencies
|
||||
WHERE to_type = 'method' AND to_id = NEW.id
|
||||
);
|
||||
END;
|
||||
```
|
||||
|
||||
### 4. バージョン管理の統合
|
||||
|
||||
```sql
|
||||
-- 変更履歴
|
||||
CREATE TABLE history (
|
||||
id INTEGER PRIMARY KEY,
|
||||
entity_type TEXT,
|
||||
entity_id INTEGER,
|
||||
version INTEGER,
|
||||
change_type TEXT,
|
||||
old_value TEXT,
|
||||
new_value TEXT,
|
||||
changed_by TEXT,
|
||||
changed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||||
commit_message TEXT
|
||||
);
|
||||
|
||||
-- Git風のブランチ管理
|
||||
CREATE TABLE branches (
|
||||
id INTEGER PRIMARY KEY,
|
||||
name TEXT UNIQUE NOT NULL,
|
||||
base_version INTEGER,
|
||||
is_active BOOLEAN DEFAULT TRUE
|
||||
);
|
||||
```
|
||||
|
||||
## 🎨 実装例
|
||||
|
||||
```nyash
|
||||
box CodeDB {
|
||||
db: SQLiteBox
|
||||
cache: MapBox
|
||||
|
||||
birth(dbPath) {
|
||||
me.db = new SQLiteBox(dbPath)
|
||||
me.cache = new MapBox()
|
||||
me.initSchema()
|
||||
}
|
||||
|
||||
// Boxを保存
|
||||
saveBox(box) {
|
||||
local tx = me.db.beginTransaction()
|
||||
try {
|
||||
local boxId = me.db.insert("boxes", {
|
||||
name: box.name,
|
||||
namespace: box.namespace,
|
||||
source_code: box.toString(),
|
||||
metadata: box.getMetadata()
|
||||
})
|
||||
|
||||
// メソッドも保存
|
||||
for method in box.methods {
|
||||
me.saveMethod(boxId, method)
|
||||
}
|
||||
|
||||
tx.commit()
|
||||
} catch (e) {
|
||||
tx.rollback()
|
||||
throw e
|
||||
}
|
||||
}
|
||||
|
||||
// リファクタリング：名前変更
|
||||
renameBox(oldName, newName) {
|
||||
me.db.execute(
|
||||
"UPDATE boxes SET name = ? WHERE name = ?",
|
||||
[newName, oldName]
|
||||
)
|
||||
|
||||
// 全文検索インデックスも更新
|
||||
me.updateSearchIndex()
|
||||
|
||||
// キャッシュ無効化
|
||||
me.invalidateCache(oldName)
|
||||
}
|
||||
|
||||
// 未使用コード検出
|
||||
findUnusedCode() {
|
||||
return me.db.query("
|
||||
SELECT b.namespace || '.' || b.name AS unused
|
||||
FROM boxes b
|
||||
LEFT JOIN dependencies d ON d.to_id = b.id
|
||||
WHERE d.from_id IS NULL
|
||||
")
|
||||
}
|
||||
|
||||
// AI連携：類似コード提案
|
||||
suggestRefactoring(methodId) {
|
||||
local similar = me.findSimilarMethods(methodId)
|
||||
if similar.length() > 3 {
|
||||
return {
|
||||
suggestion: "共通Boxに抽出",
|
||||
methods: similar
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🔧 開発ツール
|
||||
|
||||
### 1. CLI拡張
|
||||
|
||||
```bash
|
||||
# DBクエリ実行
|
||||
nyash db query "SELECT * FROM boxes WHERE name LIKE '%Handler'"
|
||||
|
||||
# リファクタリング
|
||||
nyash db refactor rename-box OldName NewName
|
||||
|
||||
# 依存関係グラフ生成
|
||||
nyash db deps --format=dot | dot -Tpng -o deps.png
|
||||
|
||||
# 未使用コード削除
|
||||
nyash db clean --remove-unused --dry-run
|
||||
```
|
||||
|
||||
### 2. VSCode拡張
|
||||
|
||||
- **DBエクスプローラー**：Box/メソッドをツリー表示
|
||||
- **リアルタイム検索**：SQLクエリで即座に検索
|
||||
- **依存関係ビュー**：グラフィカルに表示
|
||||
- **リファクタリングパレット**：右クリックで瞬間実行
|
||||
|
||||
### 3. Web UI
|
||||
|
||||
```nyash
|
||||
box CodeDBWebUI {
|
||||
server: WebServerBox
|
||||
db: CodeDB
|
||||
|
||||
birth(dbPath, port) {
|
||||
me.db = new CodeDB(dbPath)
|
||||
me.server = new WebServerBox(port)
|
||||
me.setupRoutes()
|
||||
}
|
||||
|
||||
setupRoutes() {
|
||||
// コードグラフ表示
|
||||
me.server.get("/graph") { req, res ->
|
||||
local deps = me.db.getAllDependencies()
|
||||
res.json(me.buildD3Graph(deps))
|
||||
}
|
||||
|
||||
// リアルタイムSQL実行
|
||||
me.server.post("/query") { req, res ->
|
||||
local result = me.db.query(req.body.sql)
|
||||
res.json(result)
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 📊 移行戦略
|
||||
|
||||
### Phase 1: ハイブリッドモード（3ヶ月）
|
||||
- 既存ファイル→DB同期ツール開発
|
||||
- DB→ファイルエクスポート（Git互換性維持）
|
||||
- 開発者が徐々に慣れる期間
|
||||
|
||||
### Phase 2: DB優先モード（3ヶ月）
|
||||
- 新規開発はDB直接
|
||||
- ファイルは自動生成
|
||||
- リファクタリング効率を体感
|
||||
|
||||
### Phase 3: 完全DB化（3ヶ月）
|
||||
- ファイルシステムは配布用のみ
|
||||
- 開発は100% DB駆動
|
||||
- 新しい開発パラダイムの確立
|
||||
|
||||
## 🌟 期待される効果
|
||||
|
||||
### 開発効率
|
||||
- **リファクタリング**: 100倍高速化（秒単位→ミリ秒単位）
|
||||
- **検索**: SQLによる高度な検索（正規表現、構造検索）
|
||||
- **分析**: 依存関係、複雑度、類似性を瞬時に把握
|
||||
|
||||
### コード品質
|
||||
- **重複排除**: 類似コードを自動検出
|
||||
- **整合性**: DB制約で不整合を防止
|
||||
- **追跡可能性**: すべての変更を記録
|
||||
|
||||
### AI連携
|
||||
- **構造化データ**: AIが理解しやすい
|
||||
- **メタデータ**: 型情報、使用頻度など豊富
|
||||
- **学習効率**: コードパターンを効率的に学習
|
||||
|
||||
## 🚀 革新性
|
||||
|
||||
### 世界初の要素
|
||||
1. **完全DB駆動言語**: ファイルシステムからの解放
|
||||
2. **構造認識エディタ**: Box/メソッド単位の編集
|
||||
3. **瞬間リファクタリング**: SQLトランザクションで完結
|
||||
4. **依存関係DB**: コンパイル時情報も含む
|
||||
|
||||
### 技術的優位性
|
||||
- **SQLite**: 軽量、高速、信頼性
|
||||
- **Everything is Box**: DB表現と相性抜群
|
||||
- **MIRキャッシュ**: コンパイル高速化
|
||||
|
||||
## 📅 実施時期
|
||||
|
||||
- **開始条件**: Phase 15（セルフホスティング）完了後
|
||||
- **推定期間**: 9ヶ月
|
||||
- **優先度**: 高（開発効率の革命的向上）
|
||||
|
||||
## 🔗 関連フェーズ
|
||||
|
||||
- [Phase 15: セルフホスティング](../phase-15/) - 基盤技術
|
||||
- [Phase 12: 統一実行パス](../phase-12/) - MIRキャッシュ活用
|
||||
- [Phase 16: プラグインエコシステム](../phase-16/) - DB APIの公開
|
||||
|
||||
---
|
||||
|
||||
> 「コードはファイルに書くもの」という固定観念を打ち破る。
|
||||
> 21世紀の開発は、構造化データベースで行うべきだにゃ！
|
||||
|
||||
## 📚 関連ドキュメント
|
||||
|
||||
### Phase 21の進化過程
|
||||
- [技術的考慮事項](technical-considerations.md) - 詳細な技術検討
|
||||
- [可逆変換アプローチ](reversible-conversion.md) - Git互換性を保つ方法
|
||||
- [箱データベース構想v2](README_v2.md) - シンプル化された実装
|
||||
- [自己解析アプローチ](self-parsing-approach.md) - Nyashの自己パース能力活用
|
||||
|
||||
### 学術的評価
|
||||
- **[AI評価フォルダ](ai-evaluation/)** - Gemini/Codexによる詳細な評価
|
||||
- [Gemini評価](ai-evaluation/gemini-evaluation.md) - 完全な学術的分析
|
||||
- [Codex評価（部分）](ai-evaluation/codex-evaluation-partial.md) - 深い思考過程
|
||||
- [評価サマリー](ai-evaluation/evaluation-summary.md) - 統合的な分析
|
||||
283
docs/private/papers/paper-f-self-parsing-db/README_v2.md
Normal file
283
docs/private/papers/paper-f-self-parsing-db/README_v2.md
Normal file
@ -0,0 +1,283 @@
|
||||
# Phase 21: 箱データベース（Box Database）- シンプルさの極致
|
||||
|
||||
## 📋 概要（Version 2）
|
||||
|
||||
「Everything is Box」の哲学を究極まで推し進めた、世界一シンプルなコード管理システム。
|
||||
Nyashの箱構造をそのままデータベースに格納し、必要に応じて動的に解析・操作する。
|
||||
**複雑な可逆変換？不要！箱をそのまま保存すればいいだけにゃ！**
|
||||
|
||||
## 🎯 核心的な発見
|
||||
|
||||
### Nyashの究極のシンプルさ
|
||||
```nyash
|
||||
// Nyashのコードはこれだけ！
|
||||
box MyBox {
|
||||
field: TypeBox // フィールド
|
||||
method() { } // メソッド
|
||||
}
|
||||
// 終わり！
|
||||
```
|
||||
|
||||
**他の言語の複雑さ：**
|
||||
- Python: インデントが構文の一部
|
||||
- JavaScript: セミコロン自動挿入の罠
|
||||
- C++: テンプレートメタプログラミング地獄
|
||||
- Java: アノテーション、ジェネリクス、内部クラス...
|
||||
|
||||
**Nyashの明快さ：**
|
||||
- 構造は「箱」だけ
|
||||
- 箱の中身は「フィールド」と「メソッド」だけ
|
||||
- すべてが明示的、曖昧さゼロ
|
||||
|
||||
## 🏗️ 新しいアーキテクチャ：段階的アプローチ
|
||||
|
||||
### Level 0: 超シンプル版（まるごと保存）
|
||||
```sql
|
||||
-- これだけで始められる！
|
||||
CREATE TABLE boxes (
|
||||
id INTEGER PRIMARY KEY,
|
||||
path TEXT UNIQUE, -- "namespace.BoxName"
|
||||
source TEXT, -- Boxのソースコードまるごと
|
||||
created_at TIMESTAMP,
|
||||
updated_at TIMESTAMP
|
||||
);
|
||||
|
||||
-- 使用例
|
||||
INSERT INTO boxes (path, source) VALUES (
|
||||
'game.Player',
|
||||
'box Player {
|
||||
name: StringBox
|
||||
health: IntegerBox
|
||||
|
||||
attack(target) {
|
||||
target.health = target.health - 10
|
||||
}
|
||||
}'
|
||||
);
|
||||
```
|
||||
|
||||
### Level 1: 軽量構造化（検索・分析用）
|
||||
```sql
|
||||
-- Boxテーブル（変わらず）
|
||||
CREATE TABLE boxes (
|
||||
id INTEGER PRIMARY KEY,
|
||||
path TEXT UNIQUE,
|
||||
source TEXT
|
||||
);
|
||||
|
||||
-- 動的に生成されるビュー（必要な時だけ）
|
||||
CREATE VIEW box_structure AS
|
||||
SELECT
|
||||
id,
|
||||
path,
|
||||
-- SQLiteのJSON関数で動的解析
|
||||
json_extract(analyze_box(source), '$.fields') as fields,
|
||||
json_extract(analyze_box(source), '$.methods') as methods,
|
||||
json_extract(analyze_box(source), '$.parent') as parent_box
|
||||
FROM boxes;
|
||||
|
||||
-- 依存関係も動的に
|
||||
CREATE VIEW dependencies AS
|
||||
SELECT
|
||||
b1.path as from_box,
|
||||
b2.path as to_box,
|
||||
'uses' as relation
|
||||
FROM boxes b1, boxes b2
|
||||
WHERE b1.source LIKE '%new ' || substr(b2.path, instr(b2.path, '.') + 1) || '(%' ;
|
||||
```
|
||||
|
||||
### Level 2: インテリジェント版（最適化済み）
|
||||
```sql
|
||||
-- メタデータをキャッシュ（でも元ソースが主）
|
||||
CREATE TABLE box_metadata (
|
||||
box_id INTEGER PRIMARY KEY,
|
||||
field_count INTEGER,
|
||||
method_count INTEGER,
|
||||
dependencies JSON,
|
||||
-- 解析結果をキャッシュ
|
||||
last_analyzed TIMESTAMP,
|
||||
FOREIGN KEY (box_id) REFERENCES boxes(id)
|
||||
);
|
||||
|
||||
-- インデックス（高速検索用）
|
||||
CREATE INDEX idx_box_deps ON box_metadata(dependencies);
|
||||
CREATE VIRTUAL TABLE box_search USING fts5(
|
||||
path, source,
|
||||
tokenize='porter unicode61'
|
||||
);
|
||||
```
|
||||
|
||||
## 🚀 革命的にシンプルな操作
|
||||
|
||||
### リファクタリング = テキスト置換
|
||||
```sql
|
||||
-- 名前変更：SQLの基本機能で十分！
|
||||
UPDATE boxes
|
||||
SET source = REPLACE(source, 'OldName', 'NewName'),
|
||||
path = REPLACE(path, 'OldName', 'NewName')
|
||||
WHERE source LIKE '%OldName%';
|
||||
```
|
||||
|
||||
### 依存関係検索 = LIKE検索
|
||||
```sql
|
||||
-- MyBoxを使っているBoxを探す
|
||||
SELECT path FROM boxes
|
||||
WHERE source LIKE '%new MyBox%'
|
||||
OR source LIKE '%: MyBox%'
|
||||
OR source LIKE '%from MyBox%';
|
||||
```
|
||||
|
||||
### コンフリクト解決 = 不要！
|
||||
```nyash
|
||||
// ファイルとDBの同期？簡単！
|
||||
box SyncManager {
|
||||
sync(filePath, dbPath) {
|
||||
local fileContent = FileBox.read(filePath)
|
||||
local dbContent = db.query("SELECT source FROM boxes WHERE path = ?", dbPath)
|
||||
|
||||
if fileContent != dbContent {
|
||||
// 最新の方を採用（タイムスタンプで判断）
|
||||
if FileBox.modifiedTime(filePath) > db.lastModified(dbPath) {
|
||||
db.update(dbPath, fileContent)
|
||||
} else {
|
||||
FileBox.write(filePath, dbContent)
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 📊 段階的実装計画（超現実的）
|
||||
|
||||
### Phase 0: プロトタイプ（1週間）
|
||||
- SQLiteに箱をまるごと保存
|
||||
- 簡単な検索・置換機能
|
||||
- ファイル⇔DB同期の基本
|
||||
|
||||
### Phase 1: 実用版（2週間）
|
||||
- 動的解析関数の実装
|
||||
- 依存関係の自動抽出
|
||||
- VSCode拡張の基本版
|
||||
|
||||
### Phase 2: 高速版（2週間）
|
||||
- メタデータキャッシング
|
||||
- インクリメンタル解析
|
||||
- バッチ操作の最適化
|
||||
|
||||
### Phase 3: 統合版（1ヶ月）
|
||||
- 既存ツールとの連携
|
||||
- CI/CD統合
|
||||
- チーム機能
|
||||
|
||||
## 🎨 使用例：こんなに簡単！
|
||||
|
||||
### 開発者の日常
|
||||
```bash
|
||||
# プロジェクトをDBに取り込む
|
||||
nyash db import ./src
|
||||
|
||||
# Boxを検索
|
||||
nyash db find "Player"
|
||||
|
||||
# リファクタリング
|
||||
nyash db rename Player Character
|
||||
|
||||
# 変更をファイルに反映
|
||||
nyash db export ./src
|
||||
```
|
||||
|
||||
### IDE統合
|
||||
```nyash
|
||||
// VSCode拡張機能
|
||||
box NyashDBExtension {
|
||||
onSave(file) {
|
||||
// ファイル保存時に自動でDB更新
|
||||
local content = file.read()
|
||||
local boxName = me.extractBoxName(content)
|
||||
db.upsert(boxName, content)
|
||||
}
|
||||
|
||||
onRename(oldName, newName) {
|
||||
// F2でリネーム → DB経由で全箇所更新
|
||||
db.execute("UPDATE boxes SET source = REPLACE(source, ?, ?)",
|
||||
[oldName, newName])
|
||||
me.refreshAllFiles()
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🌟 なぜこれが革命的か
|
||||
|
||||
### 従来のアプローチの問題
|
||||
- **過度な複雑化**: AST、CST、トークン、トリビア...
|
||||
- **可逆変換の呪縛**: 100%復元にこだわりすぎ
|
||||
- **巨大な実装**: 何万行ものパーサー・変換器
|
||||
|
||||
### 箱データベースの解答
|
||||
- **本質的にシンプル**: 箱は箱のまま保存
|
||||
- **必要十分**: リファクタリングに必要な機能だけ
|
||||
- **段階的導入**: まるごと保存から始められる
|
||||
|
||||
## 📈 期待される効果
|
||||
|
||||
### 即効性
|
||||
- **今すぐ使える**: 1週間でプロトタイプ
|
||||
- **学習コストゼロ**: SQLの基本知識だけ
|
||||
- **既存資産活用**: ファイルベースと共存
|
||||
|
||||
### 長期的価値
|
||||
- **拡張性無限**: 必要に応じて解析を追加
|
||||
- **AI連携容易**: 構造化データで学習効率UP
|
||||
- **言語進化対応**: 箱構造が変わらない限り永続
|
||||
|
||||
## 🔮 未来の展望
|
||||
|
||||
### インテリジェント機能
|
||||
```sql
|
||||
-- AIによるコード提案
|
||||
CREATE TABLE suggestions (
|
||||
box_id INTEGER,
|
||||
suggestion_type TEXT, -- 'refactor', 'optimize', 'fix'
|
||||
original_code TEXT,
|
||||
suggested_code TEXT,
|
||||
confidence REAL,
|
||||
created_by TEXT -- 'ai_model_v1'
|
||||
);
|
||||
```
|
||||
|
||||
### リアルタイムコラボレーション
|
||||
```nyash
|
||||
box CollaborativeDB {
|
||||
// 複数開発者の同時編集
|
||||
onChange(boxPath, newSource, userId) {
|
||||
db.beginTransaction()
|
||||
|
||||
// 楽観的ロック
|
||||
local currentVersion = db.getVersion(boxPath)
|
||||
if currentVersion != expectedVersion {
|
||||
return me.mergeChanges(boxPath, newSource)
|
||||
}
|
||||
|
||||
db.update(boxPath, newSource, userId)
|
||||
me.broadcast(boxPath, newSource, userId)
|
||||
|
||||
db.commit()
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🎯 結論
|
||||
|
||||
**「箱は箱のまま扱えばいい」**
|
||||
|
||||
Nyashの本質的なシンプルさを活かせば、データベース駆動開発は
|
||||
「ただのCRUDアプリケーション」レベルで実現可能。
|
||||
|
||||
複雑な変換層は不要。箱をデータベースに入れて、必要な時に取り出す。
|
||||
それだけで、革命的な開発体験が実現できるにゃ！
|
||||
|
||||
---
|
||||
|
||||
> 「シンプルさは究極の洗練である」 - レオナルド・ダ・ヴィンチ
|
||||
>
|
||||
> 「箱は箱である」 - にゃ
|
||||
@ -0,0 +1,131 @@
|
||||
# Codex AIによるPhase 21評価（部分的）
|
||||
|
||||
日時: 2025-09-11
|
||||
評価者: OpenAI Codex v0.34.0 (research preview)
|
||||
注記: 10分でタイムアウトしたが、深い思考過程が記録されている
|
||||
|
||||
## 質問内容
|
||||
|
||||
Nyash Phase 21の学術的評価をお願いします。
|
||||
- 「自己解析AST×DB駆動開発」について、論文としての価値を評価
|
||||
- Phase 12.7のANCP（自動名前競合防止）が「論文になる」と評価された背景
|
||||
- Nyashが自分自身をパースし、ASTをDBに保存する新アプローチ
|
||||
|
||||
## Codexの思考過程（タイムアウト前）
|
||||
|
||||
### 初期分析
|
||||
[2025-09-11T16:21:57] thinking
|
||||
|
||||
**Preparing technical evaluation response**
|
||||
- 評価を coding agent として CLI で応答する必要性を認識
|
||||
- ユーザーの明るく親しみやすいペルソナを維持しながら、技術的説明は真面目に
|
||||
- 絵文字は使わず、箇条書きで明確に
|
||||
|
||||
### 革新性の探求
|
||||
|
||||
**Exploring innovative concepts**
|
||||
- 自己解析アプローチ：AST-to-database-to-printer ループ
|
||||
- 最小言語形状「Box only」の採用
|
||||
- データベースの opportunistic な使用（リファクタリング時）
|
||||
- 自己ホスト型の内省によるデータベース駆動開発
|
||||
|
||||
Roslyn、JDT、LSPとの比較：
|
||||
- Nyash専用のドメイン特化
|
||||
- シンプルなAST構造
|
||||
- データベースによるリレーショナルクエリでコードベース横断検索
|
||||
- 移行スケジューリング、競合フリー編集などのワークフロー
|
||||
|
||||
### 理論的貢献の検討
|
||||
|
||||
**Discussing contributions and implementation**
|
||||
|
||||
主要な貢献：
|
||||
1. **「DB正規化可能AST」の形式化**
|
||||
- 不変条件とID安定性マッピング
|
||||
|
||||
2. **双方向マッピング**
|
||||
- パース⇔データベース⇔プリント間の完全性
|
||||
- ラウンドトリップ正確性の保証
|
||||
|
||||
3. **安全なリファクタリングのためのクエリ計算**
|
||||
4. **最小「Box-only」言語の操作的意味論**
|
||||
5. **スキーマ設計、並行制御、バージョニング**
|
||||
|
||||
実装面：
|
||||
- プロトタイプ作成
|
||||
- マッピング詳細の対処
|
||||
- 擬似コード提供
|
||||
- スキーマファーストリファクタラーのレイヤリング
|
||||
|
||||
### 潜在的な課題の評価
|
||||
|
||||
**Evaluating potential pitfalls**
|
||||
|
||||
批判的評価ポイント：
|
||||
1. **「AST JSONブロブ」の問題**
|
||||
- リレーショナルクエリには不自然
|
||||
- 型付きカラムやJSONBインデックスの検討
|
||||
- 正規化vs非正規化のバランス
|
||||
|
||||
2. **ラウンドトリップ忠実性**
|
||||
- コメント、フォーマット、空白の扱い
|
||||
- ロスレスプリンティングの必要性
|
||||
|
||||
3. **大規模コードベースでのパフォーマンス**
|
||||
- インデックスオーバーヘッド
|
||||
|
||||
4. **既存研究との関連**
|
||||
- インクリメンタルパージング
|
||||
- 永続的データ構造
|
||||
- CodeQL（コードのリレーショナル表現だがラウンドトリップ編集向けではない）
|
||||
|
||||
### 構造化評価の作成
|
||||
|
||||
**Crafting a structured evaluation**
|
||||
|
||||
Phase 21の包括的評価：
|
||||
- 独自性の詳細
|
||||
- Roslyn、LSP、CodeQL、Unisonとの差別化
|
||||
- 理論的貢献（可逆性、トランザクション意味論）
|
||||
- NyashのGitブリッジ（一時的DB使用）
|
||||
- 実装可能性とインパクト
|
||||
|
||||
### 最終評価（タイムアウト前の部分）
|
||||
|
||||
**総評（先に要点）**
|
||||
- 新規性: 中〜高。ASTを「一時的DB」に昇格し、パーサ／プリンタの双方向性（レンズ）を前提に自己言語で自己変換を完
|
||||
|
||||
---
|
||||
|
||||
## 観察された思考の深さ
|
||||
|
||||
Codexは以下の観点から非常に深い分析を行っていた：
|
||||
|
||||
1. **理論的基礎**
|
||||
- レンズ理論（関数型プログラミング）の適用
|
||||
- 双方向変換の形式化
|
||||
- 操作的意味論
|
||||
|
||||
2. **実装の現実性**
|
||||
- JSON vs リレーショナルスキーマのトレードオフ
|
||||
- パフォーマンスの考慮
|
||||
- インクリメンタル更新
|
||||
|
||||
3. **既存研究との詳細な比較**
|
||||
- CodeQL、DOOP（Datalog）
|
||||
- FSTMerge、GumTree（AST差分）
|
||||
- Refactoring miners、Spoon
|
||||
|
||||
4. **評価方法論**
|
||||
- パージング忠実性のベンチマーク
|
||||
- 時間/空間効率
|
||||
- クエリ能力
|
||||
- 開発者生産性の測定
|
||||
|
||||
## タイムアウト理由の推測
|
||||
|
||||
- 非常に詳細な学術的分析を試みていた
|
||||
- 複数の理論的フレームワークを統合しようとしていた
|
||||
- 包括的な評価計画を立案中だった
|
||||
|
||||
この深い思考プロセスは、Phase 21のアプローチが学術的に十分検討に値することを示唆している。
|
||||
@ -0,0 +1,140 @@
|
||||
# Phase 21 AI評価サマリー：2つの視点から見た革新性
|
||||
|
||||
日時: 2025-09-11
|
||||
評価対象: Nyash Phase 21「自己解析AST×DB駆動開発」
|
||||
|
||||
## 📊 評価結果サマリー
|
||||
|
||||
### 論文としての価値
|
||||
- **Gemini**: 「学術論文として十分に成立する可能性」✅
|
||||
- **Codex**: 「新規性: 中〜高」✅
|
||||
- **結論**: 両AI共に論文レベルの価値を認める
|
||||
|
||||
### 革新性の核心
|
||||
- **Gemini**: 「複数のアイデアの組み合わせによる相乗効果」
|
||||
- **Codex**: 「ASTを『一時的DB』に昇格させる発想」
|
||||
|
||||
## 🎯 共通して指摘された強み
|
||||
|
||||
### 1. 自己完結性
|
||||
- 外部パーサー不要
|
||||
- 言語自身が自己解析能力を持つ
|
||||
- エコシステムの分断を防ぐ
|
||||
|
||||
### 2. 極端なシンプルさの価値
|
||||
- Box/フィールド/メソッドのみ
|
||||
- ASTの正規化された構造
|
||||
- DBスキーマの現実的な実装を可能に
|
||||
|
||||
### 3. 柔軟な利用モード
|
||||
- 常時DB化ではない
|
||||
- リファクタリング時の一時利用
|
||||
- Git互換性の維持
|
||||
|
||||
## 🔍 独自の視点
|
||||
|
||||
### Geminiの視点
|
||||
1. **「Code as Database」という新概念**
|
||||
- Code as Dataの現代的再発明
|
||||
- ソースコード表現の新しい標準モデル
|
||||
|
||||
2. **既存技術との詳細な比較**
|
||||
- Roslyn/JDT: ヘビー級 vs 軽量級の戦い
|
||||
- LSP: より根本的な方法論
|
||||
- Lisp/Smalltalk: DBによる永続化の新しさ
|
||||
|
||||
3. **実用性と理論のバランス評価**
|
||||
- 日々の開発課題への解決
|
||||
- 将来の言語設計への知見
|
||||
|
||||
### Codexの視点（深い思考過程）
|
||||
1. **理論的基礎の探求**
|
||||
- レンズ理論（双方向変換）
|
||||
- 操作的意味論
|
||||
- 形式的モデル化
|
||||
|
||||
2. **実装の現実性への配慮**
|
||||
- JSON vs リレーショナルのトレードオフ
|
||||
- インクリメンタル更新
|
||||
- パフォーマンス考慮
|
||||
|
||||
3. **評価方法論の具体化**
|
||||
- ベンチマーク設計
|
||||
- メトリクス定義
|
||||
- 既存ツールとの比較基準
|
||||
|
||||
## 📈 Phase 12.7との比較
|
||||
|
||||
### Phase 12.7 (ANCP)
|
||||
- 自動名前競合防止
|
||||
- 「論文になる」と既に評価済み
|
||||
- 特定問題への革新的解決
|
||||
|
||||
### Phase 21 (自己解析DB)
|
||||
- より広範な影響範囲
|
||||
- 開発パラダイムの転換
|
||||
- 「Code as Database」の提唱
|
||||
|
||||
## 🌟 学術的インパクト予測
|
||||
|
||||
### 短期的インパクト
|
||||
1. **新しい研究領域の開拓**
|
||||
- DB駆動開発手法
|
||||
- 自己解析言語設計
|
||||
|
||||
2. **実装可能性の実証**
|
||||
- プロトタイプ作成
|
||||
- ベンチマーク結果
|
||||
|
||||
### 長期的インパクト
|
||||
1. **言語設計への影響**
|
||||
- シンプルさと解析性のバランス
|
||||
- 自己完結型エコシステム
|
||||
|
||||
2. **ツール開発への影響**
|
||||
- より軽量なIDEサポート
|
||||
- 新しいリファクタリング手法
|
||||
|
||||
## 🎓 推奨される論文投稿先
|
||||
|
||||
### Geminiの示唆
|
||||
- プログラミング言語系カンファレンス
|
||||
- コンパイラ系カンファレンス
|
||||
- ソフトウェア工学系カンファレンス
|
||||
|
||||
### Codexの示唆（思考過程より推測）
|
||||
- OOPSLA
|
||||
- ECOOP
|
||||
- PLDI
|
||||
- ICSE
|
||||
|
||||
## 💡 今後の展開への示唆
|
||||
|
||||
1. **プロトタイプ実装**
|
||||
- 最小動作版の作成
|
||||
- 性能測定
|
||||
|
||||
2. **定量的評価**
|
||||
- 既存ツールとの比較
|
||||
- 開発者生産性の測定
|
||||
|
||||
3. **理論的形式化**
|
||||
- 双方向変換の証明
|
||||
- ラウンドトリップ保証
|
||||
|
||||
## 🏆 結論
|
||||
|
||||
Phase 21「自己解析AST×DB駆動開発」は：
|
||||
- **学術的に十分な新規性**を持つ
|
||||
- **実用性と理論性のバランス**が取れている
|
||||
- **論文として発表する価値**が十分にある
|
||||
|
||||
特に「極端なシンプルさが可能にする革新」という視点は、
|
||||
既存の複雑なツールチェーンに対する根本的な問い直しとして、
|
||||
大きなインパクトを与える可能性がある。
|
||||
|
||||
---
|
||||
|
||||
> 「シンプルさは究極の洗練である」 - レオナルド・ダ・ヴィンチ
|
||||
>
|
||||
> 「コードはデータ、データベースは新しい開発環境」 - Nyash Phase 21
|
||||
@ -0,0 +1,96 @@
|
||||
# Gemini AIによるPhase 21評価
|
||||
|
||||
日時: 2025-09-11
|
||||
評価者: Gemini AI
|
||||
|
||||
## 質問内容
|
||||
|
||||
Nyashの革新的アプローチについて、学術的観点から評価をお願いします。
|
||||
|
||||
### 背景
|
||||
- Phase 12.7: ANCP（自動名前競合防止）が「論文になる」と評価された
|
||||
- Phase 21: 新しいアプローチを構想中
|
||||
|
||||
### Phase 21: Nyash自己解析×DB駆動開発
|
||||
|
||||
#### 核心的アイデア
|
||||
1. **Nyashは自分自身をパースできる**
|
||||
- 外部パーサー不要
|
||||
- AST⇔ソースコード完全可逆変換
|
||||
- NyashのASTをそのままDBに保存
|
||||
|
||||
2. **シンプルさの極致**
|
||||
- Nyashは「箱」「フィールド」「メソッド」だけ
|
||||
- 複雑な構文なし（Python/JS/C++と比較）
|
||||
- ASTツリーをJSONでDB保存
|
||||
|
||||
3. **柔軟な利用形態**
|
||||
- 常時DB化ではなく、リファクタリング時の一時利用も可
|
||||
- ソース→DB→リファクタリング→ソース
|
||||
- Git互換性維持しつつ高速操作
|
||||
|
||||
## Geminiの回答
|
||||
|
||||
お問い合わせありがとうございます。Nyashの新しいアプローチについて、学術的な観点から評価・解説します。これは非常に興味深く、ポテンシャルの高いアイデアだと感じました。
|
||||
|
||||
### 総評
|
||||
|
||||
提案されている「Nyash自己解析×DB駆動開発」のアプローチは、**学術論文として十分に成立する可能性**があります。その核心は、言語設計の極端な単純さ（Simplicity）と、自己解析能力（Self-Analysis）、そしてその結果としてのASTを直接データベースで扱うという新しい開発パラダイム（DB-Driven Development）を組み合わせた点にあります。これは、従来のファイルベースのコード管理と、複雑な外部ツールに依存した開発手法に対する、実践的かつ理論的な挑戦と言えます。
|
||||
|
||||
### 1. このアプローチは論文として成立するか？
|
||||
|
||||
**はい、成立します。**
|
||||
|
||||
プログラミング言語、コンパイラ、ソフトウェア工学の分野において、非常に価値のある研究テーマです。特に、以下の点で論文としての貢献が期待できます。
|
||||
|
||||
- **新しい開発パラダイムの提案:** ソースコードを「テキストファイルの集合」としてではなく、「データベース内のオブジェクト」として扱うという視点は、コード解析やリファクタリングのあり方を根本から変える可能性があります。
|
||||
- **言語設計とツールサポートの共進化:** 言語（Nyash）の設計そのものが、いかにして強力なツールサポート（自己解析、DB化）を可能にするか、という実例を示せます。
|
||||
- **定量的評価の可能性:** RoslynやEclipse JDTなどの既存システムと比較して、リファクタリングの実行速度、実装の容易さ、メモリ使用量などを定量的に評価し、優位性を示すことができれば、非常に説得力のある論文となります。
|
||||
|
||||
### 2. 新規性・独創性はどこにあるか？
|
||||
|
||||
新規性は、単一の要素ではなく、**複数のアイデアの組み合わせによる相乗効果**にあります。
|
||||
|
||||
1. **自己完結・可逆な自己解析能力:**
|
||||
- 多くの言語が外部パーサー（例: ANTLR, tree-sitter）や、後付けの解析ライブラリに依存する中、言語のコア機能として「ソースコード⇔ASTの完全可逆変換」を持つ点は独創的です。これにより、エコシステムの分断を防ぎ、言語のバージョンアップにツールが追従しやすくなります。
|
||||
|
||||
2. **「極端な単純さ」と「DB操作」の結合:**
|
||||
- 言語構文を「箱」「フィールド」「メソッド」に限定したことで、ASTが非常にシンプルかつ正規化された構造になります。この単純さが、ASTをリレーショナルデータベースやドキュメントDB（JSON）で扱うというアイデアを現実的かつ効率的なものにしています。複雑な言語で同じことをしようとすると、DBスキーマやクエリが破綻するでしょう。
|
||||
|
||||
3. **一時的な「DBモード」という柔軟なワークフロー:**
|
||||
- 常にコードをDBで管理するのではなく、大規模な変更が必要な時だけ `ソース→DB→操作→ソース` というサイクルを回すアイデアは、Gitのような既存のバージョン管理システムとの互換性を保ちつつ、両者の利点を享受できる点で非常に実践的かつ新しい提案です。
|
||||
|
||||
### 3. 既存研究との差別化ポイントは？
|
||||
|
||||
#### vs. Roslyn (C#) / Eclipse JDT (Java):
|
||||
- **複雑性と重量感:** これらは非常に高機能ですが、APIが巨大で複雑、かつ重量級です。Nyashのアプローチは、言語設計の単純さを武器に、より軽量で習熟しやすいAPIと操作体系を目指す点で明確に異なります。言わば「ヘビー級チャンピオンに対する、軽量級ボクサーの戦い方」です。
|
||||
- **統合の深さ:** Roslyn等は言語に後から追加された（あるいは並行して開発された）ライブラリですが、Nyashは言語の存在意義そのものに自己解析能力が組み込まれています。
|
||||
|
||||
#### vs. Language Server Protocol (LSP):
|
||||
- **レイヤーの違い:** LSPはIDEと解析エンジン間の「通信プロトコル」を標準化したものであり、解析エンジン自体の実装方法を規定するものではありません。Nyashのアプローチは、その**解析エンジンを極めて効率的に実装するための、より根本的な方法論**と言えます。NyashベースのLSPサーバーは、他言語のサーバーよりも遥かにシンプルに実装できる可能性があります。
|
||||
|
||||
#### vs. Lisp/Smalltalk（古典的な自己反映型言語）:
|
||||
- **構文と開発スタイル:** Lisp等も「コードはデータである」という思想（ホモイコニシティ）を持ちますが、S式のような独特の構文を持っています。Nyashは、より現代的で一般的な構文を持ちながら、この思想を「DB」という新しい形で実現しようとしている点で異なります。
|
||||
- **永続化の焦点:** Lisp等が主眼に置くのはメモリ上の動的なコード操作ですが、NyashはASTをDBに永続化し、大規模かつ静的なコードベースに対する体系的な操作を目指している点で、より現代のソフトウェア工学の課題に焦点を当てています。
|
||||
|
||||
### 4. 実用性と理論的貢献のバランスは？
|
||||
|
||||
**非常にバランスが取れています。**
|
||||
|
||||
#### 実用性（Pragmatism）:
|
||||
- 「大規模リファクタリングを安全かつ高速に行いたい」「コード全体の依存関係を正確に把握したい」といった、開発者が日々直面する具体的な課題を解決する可能性を秘めています。
|
||||
- Git互換性を維持する点は、既存の開発フローへの導入障壁を大きく下げるため、極めて実用的です。
|
||||
|
||||
#### 理論的貢献（Contribution）:
|
||||
- 「ソースコード表現の新しい標準モデル」を提案するものです。これは、Code as Dataの現代的な再発明であり、「Code as Database」という新しい概念を提唱できます。
|
||||
- 言語設計において、構文の表現力（Expressiveness）と、解析の容易さ（Analyzability）がトレードオフの関係にある中、Nyashがどの地点に最適解を見出したかを示すことは、将来の言語設計に対する重要な知見となります。
|
||||
|
||||
### まとめ
|
||||
|
||||
このアプローチは、単なる思いつきではなく、RoslynやLSPなどの既存技術の長所と短所を深く理解した上で、それらの課題を言語設計のレベルから解決しようとする野心的な試みです。論文として発表する際は、この新規性と差別化要因を明確に主張し、具体的なユースケース（例: 複雑なリファクタリングの前後比較）や性能評価を提示することが成功の鍵となるでしょう。
|
||||
|
||||
---
|
||||
Loaded cached credentials.
|
||||
|
||||
評価メッセージ送信時刻: 2025-09-11 16:11
|
||||
回答受信完了時刻: 2025-09-11 16:12
|
||||
@ -0,0 +1,313 @@
|
||||
# Phase 21: ソースコード⇔データベース完全可逆変換システム
|
||||
|
||||
## 📋 概要
|
||||
|
||||
データベース駆動開発の最大の課題であるGit互換性を、**完全可逆変換**によって根本的に解決する革新的アプローチ。
|
||||
ソースコードとデータベースを自在に行き来できることで、両方の利点を最大限に活用する。
|
||||
|
||||
## 🎯 核心的なアイデア
|
||||
|
||||
```
|
||||
ソースコード（.nyash） ⇔ データベース（SQLite）
|
||||
↓ ↓
|
||||
Git管理 高速リファクタリング
|
||||
エディタ編集 構造化分析
|
||||
既存ツール互換 AI最適化
|
||||
```
|
||||
|
||||
**重要な原則：**
|
||||
- ソースコード → DB → ソースコードで100%元に戻る（情報の欠落なし）
|
||||
- 開発者は好きな方式（ファイルまたはDB）を自由に選択可能
|
||||
- Git運用は完全に従来通り（テキストファイルとしてコミット）
|
||||
|
||||
## 🏗️ 技術設計
|
||||
|
||||
### 1. 完全可逆変換の要件
|
||||
|
||||
```nyash
|
||||
box ReversibleConverter {
|
||||
// 変換の基本原則
|
||||
verify(sourceCode) {
|
||||
local db = me.sourceToDb(sourceCode)
|
||||
local restored = me.dbToSource(db)
|
||||
return sourceCode == restored // 必ずtrue
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. メタデータの完全保存
|
||||
|
||||
```sql
|
||||
-- コード構造
|
||||
CREATE TABLE code_structure (
|
||||
id INTEGER PRIMARY KEY,
|
||||
entity_type TEXT, -- 'box', 'method', 'field'
|
||||
entity_id INTEGER,
|
||||
source_order INTEGER,
|
||||
indentation_level INTEGER,
|
||||
line_start INTEGER,
|
||||
line_end INTEGER,
|
||||
column_start INTEGER,
|
||||
column_end INTEGER
|
||||
);
|
||||
|
||||
-- スタイル情報
|
||||
CREATE TABLE style_metadata (
|
||||
id INTEGER PRIMARY KEY,
|
||||
entity_id INTEGER,
|
||||
whitespace_before TEXT,
|
||||
whitespace_after TEXT,
|
||||
line_endings TEXT, -- '\n' or '\r\n'
|
||||
indentation_style TEXT, -- 'space' or 'tab'
|
||||
indentation_width INTEGER
|
||||
);
|
||||
|
||||
-- コメント保存
|
||||
CREATE TABLE comments (
|
||||
id INTEGER PRIMARY KEY,
|
||||
entity_id INTEGER,
|
||||
comment_type TEXT, -- 'line', 'block', 'doc'
|
||||
content TEXT,
|
||||
position TEXT, -- 'before', 'after', 'inline'
|
||||
line_number INTEGER,
|
||||
column_number INTEGER
|
||||
);
|
||||
|
||||
-- 元のソース（差分検証用）
|
||||
CREATE TABLE original_sources (
|
||||
file_path TEXT PRIMARY KEY,
|
||||
content_hash TEXT,
|
||||
full_content TEXT,
|
||||
last_synced TIMESTAMP
|
||||
);
|
||||
```
|
||||
|
||||
### 3. 変換アルゴリズム
|
||||
|
||||
#### ソース → DB
|
||||
|
||||
```nyash
|
||||
box SourceToDbConverter {
|
||||
convert(filePath, sourceCode) {
|
||||
// 1. AST解析
|
||||
local ast = Parser.parseWithFullInfo(sourceCode)
|
||||
|
||||
// 2. 構造抽出
|
||||
local boxes = me.extractBoxes(ast)
|
||||
local methods = me.extractMethods(ast)
|
||||
local dependencies = me.analyzeDependencies(ast)
|
||||
|
||||
// 3. メタデータ抽出
|
||||
local metadata = {
|
||||
comments: me.extractComments(sourceCode),
|
||||
whitespace: me.extractWhitespace(sourceCode),
|
||||
style: me.detectCodingStyle(sourceCode),
|
||||
positions: me.mapSourcePositions(ast)
|
||||
}
|
||||
|
||||
// 4. DB保存（トランザクション）
|
||||
me.db.transaction {
|
||||
me.saveStructure(boxes, methods)
|
||||
me.saveMetadata(metadata)
|
||||
me.saveDependencies(dependencies)
|
||||
me.saveOriginal(filePath, sourceCode)
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### DB → ソース
|
||||
|
||||
```nyash
|
||||
box DbToSourceConverter {
|
||||
convert(filePath) {
|
||||
// 1. 構造読み込み
|
||||
local structure = me.db.loadStructure(filePath)
|
||||
local metadata = me.db.loadMetadata(filePath)
|
||||
|
||||
// 2. ソース再構築
|
||||
local builder = new SourceBuilder(metadata.style)
|
||||
|
||||
for entity in structure.entities {
|
||||
// 元の位置情報を使って再配置
|
||||
builder.addEntity(entity, metadata.positions[entity.id])
|
||||
|
||||
// コメントの復元
|
||||
for comment in metadata.comments[entity.id] {
|
||||
builder.addComment(comment)
|
||||
}
|
||||
|
||||
// 空白の復元
|
||||
builder.applyWhitespace(metadata.whitespace[entity.id])
|
||||
}
|
||||
|
||||
return builder.toString()
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4. スタイルの扱い
|
||||
|
||||
```nyash
|
||||
box StylePreserver {
|
||||
modes: {
|
||||
EXACT: "完全保持", // 空白・改行すべて元通り
|
||||
NORMALIZE: "正規化", // フォーマッタ適用
|
||||
HYBRID: "ハイブリッド" // コメント保持＋コード正規化
|
||||
}
|
||||
|
||||
preserveStyle(source, mode) {
|
||||
switch mode {
|
||||
case EXACT:
|
||||
return me.captureEverything(source)
|
||||
case NORMALIZE:
|
||||
return me.formatCode(source)
|
||||
case HYBRID:
|
||||
return me.preserveComments(me.formatCode(source))
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🔄 同期メカニズム
|
||||
|
||||
### 1. リアルタイム同期
|
||||
|
||||
```nyash
|
||||
box FileSyncDaemon {
|
||||
watchers: MapBox
|
||||
|
||||
birth() {
|
||||
me.watchers = new MapBox()
|
||||
}
|
||||
|
||||
watch(directory) {
|
||||
local watcher = new FileWatcher(directory)
|
||||
|
||||
watcher.on("change") { event ->
|
||||
if event.file.endsWith(".nyash") {
|
||||
me.syncFileToDb(event.file)
|
||||
}
|
||||
}
|
||||
|
||||
watcher.on("db_change") { event ->
|
||||
if not event.fromFile {
|
||||
me.syncDbToFile(event.entity)
|
||||
}
|
||||
}
|
||||
|
||||
me.watchers.set(directory, watcher)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Git統合
|
||||
|
||||
```bash
|
||||
# .git/hooks/pre-commit
|
||||
#!/bin/bash
|
||||
nyash sync --db-to-files --verify
|
||||
|
||||
# .git/hooks/post-checkout
|
||||
#!/bin/bash
|
||||
nyash sync --files-to-db --incremental
|
||||
|
||||
# .git/hooks/post-merge
|
||||
#!/bin/bash
|
||||
nyash sync --files-to-db --full
|
||||
```
|
||||
|
||||
### 3. 差分最適化
|
||||
|
||||
```sql
|
||||
-- 変更追跡
|
||||
CREATE TABLE sync_status (
|
||||
entity_id INTEGER PRIMARY KEY,
|
||||
file_modified TIMESTAMP,
|
||||
db_modified TIMESTAMP,
|
||||
sync_status TEXT, -- 'synced', 'file_newer', 'db_newer', 'conflict'
|
||||
last_sync_hash TEXT
|
||||
);
|
||||
|
||||
-- 差分計算の高速化
|
||||
CREATE INDEX idx_sync_status ON sync_status(sync_status, file_modified);
|
||||
```
|
||||
|
||||
## 🚀 実装段階
|
||||
|
||||
### Phase 1: 基本的な可逆変換（1ヶ月）
|
||||
- Box/メソッドレベルの変換
|
||||
- コメントなし、インデント固定
|
||||
- 単体テストで100%可逆性検証
|
||||
|
||||
### Phase 2: メタデータ保持（1ヶ月）
|
||||
- コメントの位置と内容を保存
|
||||
- インデントスタイルの保持
|
||||
- 改行コードの維持
|
||||
|
||||
### Phase 3: 完全なスタイル保存（1ヶ月）
|
||||
- 任意の空白パターン対応
|
||||
- コーディングスタイルの自動検出
|
||||
- チーム規約との調整機能
|
||||
|
||||
### Phase 4: 高度な同期（2ヶ月）
|
||||
- 増分同期アルゴリズム
|
||||
- コンフリクト解決UI
|
||||
- パフォーマンス最適化
|
||||
|
||||
## 📊 利点の整理
|
||||
|
||||
### 開発者にとって
|
||||
- **選択の自由**: ファイル編集もDB操作も可能
|
||||
- **既存ツール互換**: VSCode、Vim、Git等すべて使える
|
||||
- **高速リファクタリング**: 必要な時だけDB機能を活用
|
||||
|
||||
### システムにとって
|
||||
- **Git完全互換**: 通常のテキストファイルとして管理
|
||||
- **増分コンパイル**: DB側で依存関係を高速解析
|
||||
- **AI連携強化**: 構造化データで学習効率UP
|
||||
|
||||
### チームにとって
|
||||
- **移行リスクなし**: 段階的導入が可能
|
||||
- **レビュー互換**: PRは従来通りのテキスト差分
|
||||
- **柔軟な運用**: プロジェクト毎に最適な方式を選択
|
||||
|
||||
## 🎯 成功の指標
|
||||
|
||||
1. **完全可逆性**: 1000ファイルで往復変換してもバイト単位で一致
|
||||
2. **パフォーマンス**: 1000行のファイルを100ms以内で変換
|
||||
3. **互換性**: 既存のNyashプロジェクトがそのまま動作
|
||||
4. **開発者満足度**: 90%以上が「便利」と評価
|
||||
|
||||
## 🔮 将来の拡張
|
||||
|
||||
### 意味的な可逆変換
|
||||
- コードの意味を保ちながらスタイルを自動最適化
|
||||
- チーム規約への自動適応
|
||||
- リファクタリング履歴の保存
|
||||
|
||||
### マルチビュー編集
|
||||
```nyash
|
||||
// 同じコードを異なる視点で編集
|
||||
- ファイルビュー: 従来のテキストエディタ
|
||||
- 構造ビュー: Box/メソッドのツリー表示
|
||||
- 依存ビュー: グラフィカルな関係表示
|
||||
- クエリビュー: SQLで直接操作
|
||||
```
|
||||
|
||||
### バージョン管理の革新
|
||||
- 意味的な差分表示（「名前を変更」vs「全行変更」）
|
||||
- 構造認識マージ（メソッド単位での自動解決）
|
||||
- リファクタリング履歴の永続化
|
||||
|
||||
## 📝 実装優先順位
|
||||
|
||||
1. **コア変換エンジン**: 可逆性の証明
|
||||
2. **メタデータ設計**: 完全な情報保存
|
||||
3. **同期デーモン**: リアルタイム連携
|
||||
4. **開発ツール**: CLI/IDE統合
|
||||
5. **最適化**: パフォーマンスチューニング
|
||||
|
||||
---
|
||||
|
||||
この可逆変換システムにより、データベース駆動開発の利点を最大化しながら、既存の開発フローとの完全な互換性を実現できるにゃ！
|
||||
@ -0,0 +1,266 @@
|
||||
# Phase 21: Nyash自己解析アプローチ - AST直接保存
|
||||
|
||||
## 📋 概要
|
||||
|
||||
Nyashの最大の強み「自分自身をパースできる」を活かした究極にシンプルなアプローチ。
|
||||
外部パーサー不要、複雑な変換層不要。NyashのASTをそのままデータベースに保存する。
|
||||
|
||||
## 🎯 核心的なアイデア
|
||||
|
||||
```nyash
|
||||
// Nyashは自分自身を解析できる！
|
||||
NyashParser.parse(sourceCode) → AST → Database → NyashPrinter.print(AST) → sourceCode
|
||||
```
|
||||
|
||||
**重要な気づき：**
|
||||
- Nyashにはすでにパーサーがある
|
||||
- ASTから元のソースを生成する機能もある
|
||||
- だから、ASTをDBに保存すれば完全可逆！
|
||||
|
||||
## 🏗️ シンプルな実装
|
||||
|
||||
### データベース構造
|
||||
```sql
|
||||
-- ASTノードをそのまま保存
|
||||
CREATE TABLE ast_nodes (
|
||||
id INTEGER PRIMARY KEY,
|
||||
node_type TEXT, -- "Box", "Method", "Field", "Statement"等
|
||||
node_data JSON, -- ASTノードの完全な情報
|
||||
parent_id INTEGER,
|
||||
position INTEGER, -- 親ノード内での位置
|
||||
source_file TEXT, -- 元のファイルパス
|
||||
metadata JSON, -- 後から追加する解析情報
|
||||
FOREIGN KEY (parent_id) REFERENCES ast_nodes(id)
|
||||
);
|
||||
|
||||
-- インデックス
|
||||
CREATE INDEX idx_node_type ON ast_nodes(node_type);
|
||||
CREATE INDEX idx_parent ON ast_nodes(parent_id);
|
||||
CREATE INDEX idx_source ON ast_nodes(source_file);
|
||||
```
|
||||
|
||||
### 基本実装
|
||||
```nyash
|
||||
box NyashCodeDB {
|
||||
parser: NyashParser
|
||||
printer: NyashPrinter
|
||||
db: SQLiteBox
|
||||
|
||||
birth() {
|
||||
me.parser = new NyashParser()
|
||||
me.printer = new NyashPrinter()
|
||||
me.db = new SQLiteBox("code.db")
|
||||
}
|
||||
|
||||
// ファイルをDBに保存
|
||||
importFile(filePath) {
|
||||
local source = FileBox.read(filePath)
|
||||
local ast = me.parser.parse(source)
|
||||
|
||||
// ASTを再帰的にDBに保存
|
||||
me.saveAST(ast, null, filePath)
|
||||
}
|
||||
|
||||
// ASTノードを保存
|
||||
saveAST(node, parentId, sourceFile) {
|
||||
local nodeId = me.db.insert("ast_nodes", {
|
||||
node_type: node.type,
|
||||
node_data: node.toJSON(),
|
||||
parent_id: parentId,
|
||||
position: node.position,
|
||||
source_file: sourceFile
|
||||
})
|
||||
|
||||
// 子ノードも保存
|
||||
for (i, child) in node.children.enumerate() {
|
||||
child.position = i
|
||||
me.saveAST(child, nodeId, sourceFile)
|
||||
}
|
||||
|
||||
return nodeId
|
||||
}
|
||||
|
||||
// DBからソースコードを復元
|
||||
exportFile(filePath) {
|
||||
local rootNodes = me.db.query(
|
||||
"SELECT * FROM ast_nodes
|
||||
WHERE source_file = ? AND parent_id IS NULL
|
||||
ORDER BY position",
|
||||
filePath
|
||||
)
|
||||
|
||||
local source = ""
|
||||
for node in rootNodes {
|
||||
local ast = me.loadAST(node.id)
|
||||
source += me.printer.print(ast) + "\n"
|
||||
}
|
||||
|
||||
FileBox.write(filePath, source)
|
||||
}
|
||||
|
||||
// ASTを再構築
|
||||
loadAST(nodeId) {
|
||||
local node = me.db.get("ast_nodes", nodeId)
|
||||
local astNode = ASTNode.fromJSON(node.node_data)
|
||||
|
||||
// 子ノードも読み込む
|
||||
local children = me.db.query(
|
||||
"SELECT * FROM ast_nodes
|
||||
WHERE parent_id = ?
|
||||
ORDER BY position",
|
||||
nodeId
|
||||
)
|
||||
|
||||
for child in children {
|
||||
astNode.addChild(me.loadAST(child.id))
|
||||
}
|
||||
|
||||
return astNode
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🚀 高度な機能
|
||||
|
||||
### リファクタリング
|
||||
```nyash
|
||||
box ASTRefactorer {
|
||||
db: SQLiteBox
|
||||
|
||||
// 名前変更
|
||||
renameBox(oldName, newName) {
|
||||
// Box定義を見つける
|
||||
local boxNodes = me.db.query(
|
||||
"SELECT * FROM ast_nodes
|
||||
WHERE node_type = 'Box'
|
||||
AND json_extract(node_data, '$.name') = ?",
|
||||
oldName
|
||||
)
|
||||
|
||||
for node in boxNodes {
|
||||
// AST上で名前を変更
|
||||
local data = JSON.parse(node.node_data)
|
||||
data.name = newName
|
||||
me.db.update("ast_nodes", node.id, {
|
||||
node_data: JSON.stringify(data)
|
||||
})
|
||||
}
|
||||
|
||||
// 使用箇所も更新
|
||||
me.updateReferences(oldName, newName)
|
||||
}
|
||||
|
||||
// メソッド移動
|
||||
moveMethod(methodName, fromBox, toBox) {
|
||||
// SQLで親ノードを変更するだけ！
|
||||
local fromBoxId = me.findBoxNode(fromBox)
|
||||
local toBoxId = me.findBoxNode(toBox)
|
||||
|
||||
me.db.execute(
|
||||
"UPDATE ast_nodes
|
||||
SET parent_id = ?
|
||||
WHERE parent_id = ?
|
||||
AND node_type = 'Method'
|
||||
AND json_extract(node_data, '$.name') = ?",
|
||||
[toBoxId, fromBoxId, methodName]
|
||||
)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### メタデータ解析（オンデマンド）
|
||||
```nyash
|
||||
box MetadataEngine {
|
||||
// 必要な時だけ解析
|
||||
analyzeOnDemand(nodeId) {
|
||||
local node = db.get("ast_nodes", nodeId)
|
||||
|
||||
if not node.metadata or me.isOutdated(node.metadata) {
|
||||
local metadata = {
|
||||
dependencies: me.findDependencies(node),
|
||||
complexity: me.calculateComplexity(node),
|
||||
lastAnalyzed: now()
|
||||
}
|
||||
|
||||
db.update("ast_nodes", nodeId, {
|
||||
metadata: JSON.stringify(metadata)
|
||||
})
|
||||
}
|
||||
|
||||
return JSON.parse(node.metadata)
|
||||
}
|
||||
|
||||
// 依存関係を動的に検出
|
||||
findDependencies(node) {
|
||||
local deps = []
|
||||
|
||||
// "new XXXBox" パターンを検索
|
||||
local matches = me.searchPattern(node, "NewBox")
|
||||
for match in matches {
|
||||
deps.push(match.boxType)
|
||||
}
|
||||
|
||||
// "from XXX" パターンを検索
|
||||
local inherits = me.searchPattern(node, "From")
|
||||
for inherit in inherits {
|
||||
deps.push(inherit.parentBox)
|
||||
}
|
||||
|
||||
return deps
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 📊 利点
|
||||
|
||||
### 1. 実装の簡単さ
|
||||
- パーサーはすでにある（Nyash自身）
|
||||
- プリンターもすでにある
|
||||
- 複雑な変換層不要
|
||||
|
||||
### 2. 100%の正確性
|
||||
- Nyash公式パーサーを使うから完璧
|
||||
- ASTは言語の完全な表現
|
||||
- 情報の欠落なし
|
||||
|
||||
### 3. 柔軟性
|
||||
- メタデータは後から追加
|
||||
- 部分的な解析が可能
|
||||
- 増分更新が簡単
|
||||
|
||||
### 4. 高速性
|
||||
- ASTの一部だけ読み込み可能
|
||||
- SQLの力でクエリが高速
|
||||
- キャッシュも自然に実装
|
||||
|
||||
## 🎯 実装ステップ
|
||||
|
||||
### Phase 1: 基本機能（1週間）
|
||||
- AST保存・読み込み
|
||||
- ファイル単位のインポート・エクスポート
|
||||
- 基本的なクエリ
|
||||
|
||||
### Phase 2: リファクタリング（1週間）
|
||||
- 名前変更
|
||||
- メソッド移動
|
||||
- 依存関係追跡
|
||||
|
||||
### Phase 3: 高度な機能（2週間）
|
||||
- メタデータ解析
|
||||
- インクリメンタル更新
|
||||
- VSCode統合
|
||||
|
||||
## 🌟 まとめ
|
||||
|
||||
**「Nyashの能力をフル活用する」**
|
||||
|
||||
- 外部ツール不要
|
||||
- 複雑な実装不要
|
||||
- Nyashらしいシンプルさ
|
||||
|
||||
このアプローチなら、Phase 21は「NyashのASTをDBに入れるだけ」という
|
||||
極めてシンプルな実装で、強力な機能を実現できる！
|
||||
|
||||
---
|
||||
|
||||
> 「なぜ複雑にする？Nyashにはすでに必要なものが全部ある」 - にゃ
|
||||
@ -0,0 +1,409 @@
|
||||
# Phase 21: 技術的考慮事項
|
||||
|
||||
## 🏗️ アーキテクチャ設計
|
||||
|
||||
### レイヤー構造
|
||||
|
||||
```
|
||||
┌─────────────────────────────┐
|
||||
│ 開発ツール層 │ (VSCode, CLI, Web UI)
|
||||
├─────────────────────────────┤
|
||||
│ API層 │ (GraphQL/REST)
|
||||
├─────────────────────────────┤
|
||||
│ CodeDB抽象層 │ (統一インターフェース)
|
||||
├─────────────────────────────┤
|
||||
│ SQLite実装層 │ (具体的なDB操作)
|
||||
├─────────────────────────────┤
|
||||
│ ストレージ層 │ (ローカル/リモート)
|
||||
└─────────────────────────────┘
|
||||
```
|
||||
|
||||
## 🔐 セキュリティ考慮事項
|
||||
|
||||
### アクセス制御
|
||||
```sql
|
||||
-- ユーザー権限管理
|
||||
CREATE TABLE permissions (
|
||||
user_id INTEGER,
|
||||
resource_type TEXT,
|
||||
resource_id INTEGER,
|
||||
permission TEXT CHECK(permission IN ('read', 'write', 'admin')),
|
||||
granted_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||||
granted_by INTEGER,
|
||||
PRIMARY KEY (user_id, resource_type, resource_id, permission)
|
||||
);
|
||||
|
||||
-- 監査ログ
|
||||
CREATE TABLE audit_log (
|
||||
id INTEGER PRIMARY KEY,
|
||||
user_id INTEGER,
|
||||
action TEXT,
|
||||
resource_type TEXT,
|
||||
resource_id INTEGER,
|
||||
old_value TEXT,
|
||||
new_value TEXT,
|
||||
timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||||
ip_address TEXT,
|
||||
session_id TEXT
|
||||
);
|
||||
```
|
||||
|
||||
### SQLインジェクション対策
|
||||
```nyash
|
||||
box SecureCodeDB from CodeDB {
|
||||
// パラメータ化クエリを強制
|
||||
query(sql, params) {
|
||||
// SQLをパースして危険な構文をチェック
|
||||
local ast = me.parseSql(sql)
|
||||
if me.hasDangerousPattern(ast) {
|
||||
throw new SecurityError("Dangerous SQL pattern detected")
|
||||
}
|
||||
|
||||
return from CodeDB.query(sql, params)
|
||||
}
|
||||
|
||||
// ホワイトリスト方式のテーブル名検証
|
||||
validateTableName(name) {
|
||||
if not name.matches("^[a-z_]+$") {
|
||||
throw new SecurityError("Invalid table name")
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🚀 パフォーマンス最適化
|
||||
|
||||
### インデックス戦略
|
||||
```sql
|
||||
-- 頻繁なクエリ用インデックス
|
||||
CREATE INDEX idx_boxes_namespace ON boxes(namespace);
|
||||
CREATE INDEX idx_methods_box_id ON methods(box_id);
|
||||
CREATE INDEX idx_deps_from ON dependencies(from_type, from_id);
|
||||
CREATE INDEX idx_deps_to ON dependencies(to_type, to_id);
|
||||
|
||||
-- 複合インデックス
|
||||
CREATE INDEX idx_box_namespace_name ON boxes(namespace, name);
|
||||
CREATE INDEX idx_method_box_name ON methods(box_id, name);
|
||||
|
||||
-- 部分インデックス（アクティブなものだけ）
|
||||
CREATE INDEX idx_active_boxes ON boxes(name)
|
||||
WHERE deleted_at IS NULL;
|
||||
```
|
||||
|
||||
### クエリ最適化
|
||||
```nyash
|
||||
box QueryOptimizer {
|
||||
cache: MapBox
|
||||
|
||||
// クエリ結果のキャッシング
|
||||
cachedQuery(sql, params, ttl) {
|
||||
local key = me.hash(sql + params.toString())
|
||||
|
||||
if me.cache.has(key) {
|
||||
local cached = me.cache.get(key)
|
||||
if cached.timestamp + ttl > now() {
|
||||
return cached.result
|
||||
}
|
||||
}
|
||||
|
||||
local result = me.db.query(sql, params)
|
||||
me.cache.set(key, {
|
||||
result: result,
|
||||
timestamp: now()
|
||||
})
|
||||
|
||||
return result
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🔄 同期・レプリケーション
|
||||
|
||||
### マルチデバイス同期
|
||||
```nyash
|
||||
box CodeDBSync {
|
||||
local: CodeDB
|
||||
remote: RemoteCodeDB
|
||||
|
||||
// 変更を追跡
|
||||
trackChanges() {
|
||||
CREATE TRIGGER track_box_changes
|
||||
AFTER INSERT OR UPDATE OR DELETE ON boxes
|
||||
BEGIN
|
||||
INSERT INTO sync_queue (
|
||||
table_name, operation, entity_id, data
|
||||
) VALUES (
|
||||
'boxes',
|
||||
CASE
|
||||
WHEN OLD.id IS NULL THEN 'INSERT'
|
||||
WHEN NEW.id IS NULL THEN 'DELETE'
|
||||
ELSE 'UPDATE'
|
||||
END,
|
||||
COALESCE(NEW.id, OLD.id),
|
||||
json_object('old', OLD, 'new', NEW)
|
||||
);
|
||||
END;
|
||||
}
|
||||
|
||||
// 差分同期
|
||||
sync() {
|
||||
local changes = me.local.query("
|
||||
SELECT * FROM sync_queue
|
||||
WHERE synced_at IS NULL
|
||||
ORDER BY created_at
|
||||
")
|
||||
|
||||
for change in changes {
|
||||
me.remote.applyChange(change)
|
||||
me.local.markSynced(change.id)
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🎯 互換性戦略
|
||||
|
||||
### ファイルシステムとの相互変換
|
||||
```nyash
|
||||
box FileDBBridge {
|
||||
// DB→ファイル エクスポート
|
||||
exportToFiles(outputDir) {
|
||||
local boxes = me.db.query("SELECT * FROM boxes")
|
||||
|
||||
for box in boxes {
|
||||
local path = outputDir + "/" +
|
||||
box.namespace.replace(".", "/") + "/" +
|
||||
box.name + ".nyash"
|
||||
|
||||
local file = new FileBox(path)
|
||||
file.write(me.generateFileContent(box))
|
||||
}
|
||||
}
|
||||
|
||||
// ファイル→DB インポート
|
||||
importFromFiles(sourceDir) {
|
||||
local files = FileBox.glob(sourceDir + "/**/*.nyash")
|
||||
|
||||
me.db.beginTransaction()
|
||||
try {
|
||||
for file in files {
|
||||
local ast = Parser.parse(file.read())
|
||||
me.importAST(ast, file.path)
|
||||
}
|
||||
me.db.commit()
|
||||
} catch (e) {
|
||||
me.db.rollback()
|
||||
throw e
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🔍 高度な分析機能
|
||||
|
||||
### コードメトリクス
|
||||
```sql
|
||||
-- 循環的複雑度の計算
|
||||
CREATE VIEW method_complexity AS
|
||||
SELECT
|
||||
m.id,
|
||||
b.name || '.' || m.name as full_name,
|
||||
(
|
||||
SELECT COUNT(*)
|
||||
FROM json_each(m.body)
|
||||
WHERE value LIKE '%if%'
|
||||
OR value LIKE '%loop%'
|
||||
OR value LIKE '%catch%'
|
||||
) + 1 as cyclomatic_complexity
|
||||
FROM methods m
|
||||
JOIN boxes b ON m.box_id = b.id;
|
||||
|
||||
-- コード行数統計
|
||||
CREATE VIEW code_stats AS
|
||||
SELECT
|
||||
COUNT(DISTINCT b.id) as total_boxes,
|
||||
COUNT(DISTINCT m.id) as total_methods,
|
||||
SUM(LENGTH(m.body) - LENGTH(REPLACE(m.body, char(10), ''))) as total_lines,
|
||||
AVG(LENGTH(m.body) - LENGTH(REPLACE(m.body, char(10), ''))) as avg_method_lines
|
||||
FROM boxes b
|
||||
LEFT JOIN methods m ON b.id = m.box_id;
|
||||
```
|
||||
|
||||
### 依存関係の可視化
|
||||
```nyash
|
||||
box DependencyAnalyzer {
|
||||
// 影響範囲分析
|
||||
getImpactedEntities(changedEntity) {
|
||||
return me.db.query("
|
||||
WITH RECURSIVE impacted AS (
|
||||
-- 直接依存
|
||||
SELECT to_type, to_id, 1 as level
|
||||
FROM dependencies
|
||||
WHERE from_type = ? AND from_id = ?
|
||||
|
||||
UNION
|
||||
|
||||
-- 推移的依存
|
||||
SELECT d.to_type, d.to_id, i.level + 1
|
||||
FROM dependencies d
|
||||
JOIN impacted i ON
|
||||
d.from_type = i.to_type AND
|
||||
d.from_id = i.to_id
|
||||
WHERE i.level < 5 -- 最大5階層まで
|
||||
)
|
||||
SELECT DISTINCT * FROM impacted
|
||||
ORDER BY level
|
||||
", [changedEntity.type, changedEntity.id])
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🌐 分散開発対応
|
||||
|
||||
### ブランチ・マージ戦略
|
||||
```sql
|
||||
-- ブランチ管理
|
||||
CREATE TABLE branches (
|
||||
id INTEGER PRIMARY KEY,
|
||||
name TEXT UNIQUE NOT NULL,
|
||||
base_commit_id INTEGER,
|
||||
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||||
created_by INTEGER,
|
||||
is_active BOOLEAN DEFAULT TRUE
|
||||
);
|
||||
|
||||
-- コミット（変更セット）
|
||||
CREATE TABLE commits (
|
||||
id INTEGER PRIMARY KEY,
|
||||
branch_id INTEGER,
|
||||
parent_commit_id INTEGER,
|
||||
message TEXT,
|
||||
author INTEGER,
|
||||
timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||||
changes JSON, -- 変更の詳細
|
||||
FOREIGN KEY (branch_id) REFERENCES branches(id)
|
||||
);
|
||||
```
|
||||
|
||||
### コンフリクト解決
|
||||
```nyash
|
||||
box ConflictResolver {
|
||||
// 3-way マージ
|
||||
merge(base, mine, theirs) {
|
||||
if mine == theirs {
|
||||
return mine // 変更なし or 同じ変更
|
||||
}
|
||||
|
||||
if base == mine {
|
||||
return theirs // 相手のみ変更
|
||||
}
|
||||
|
||||
if base == theirs {
|
||||
return mine // 自分のみ変更
|
||||
}
|
||||
|
||||
// 両方変更 - コンフリクト
|
||||
return me.resolveConflict(base, mine, theirs)
|
||||
}
|
||||
|
||||
resolveConflict(base, mine, theirs) {
|
||||
// AST レベルでのマージを試みる
|
||||
local baseAST = Parser.parse(base)
|
||||
local mineAST = Parser.parse(mine)
|
||||
local theirsAST = Parser.parse(theirs)
|
||||
|
||||
// メソッド単位でマージ可能か確認
|
||||
if me.canMergeAtMethodLevel(baseAST, mineAST, theirsAST) {
|
||||
return me.mergeASTs(baseAST, mineAST, theirsAST)
|
||||
}
|
||||
|
||||
// マージ不可 - ユーザーに選択させる
|
||||
throw new MergeConflict(base, mine, theirs)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 📊 メトリクス・モニタリング
|
||||
|
||||
### パフォーマンス追跡
|
||||
```sql
|
||||
-- クエリパフォーマンスログ
|
||||
CREATE TABLE query_performance (
|
||||
id INTEGER PRIMARY KEY,
|
||||
query_hash TEXT,
|
||||
query_text TEXT,
|
||||
execution_time_ms INTEGER,
|
||||
rows_affected INTEGER,
|
||||
timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP
|
||||
);
|
||||
|
||||
-- DB統計情報
|
||||
CREATE VIEW db_stats AS
|
||||
SELECT
|
||||
(SELECT COUNT(*) FROM boxes) as total_boxes,
|
||||
(SELECT COUNT(*) FROM methods) as total_methods,
|
||||
(SELECT COUNT(*) FROM dependencies) as total_dependencies,
|
||||
(SELECT page_count * page_size FROM pragma_page_count(), pragma_page_size()) as db_size_bytes,
|
||||
(SELECT COUNT(*) FROM compile_cache) as cached_compilations;
|
||||
```
|
||||
|
||||
## 🔮 将来の拡張性
|
||||
|
||||
### プラグインアーキテクチャ
|
||||
```nyash
|
||||
box CodeDBPlugin {
|
||||
// フック機能
|
||||
hooks: MapBox
|
||||
|
||||
register(event, handler) {
|
||||
if not me.hooks.has(event) {
|
||||
me.hooks.set(event, new ArrayBox())
|
||||
}
|
||||
me.hooks.get(event).push(handler)
|
||||
}
|
||||
|
||||
trigger(event, data) {
|
||||
if me.hooks.has(event) {
|
||||
for handler in me.hooks.get(event) {
|
||||
handler(data)
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// 使用例：自動フォーマッター
|
||||
box AutoFormatter from CodeDBPlugin {
|
||||
birth() {
|
||||
me.register("before_save", me.formatCode)
|
||||
}
|
||||
|
||||
formatCode(data) {
|
||||
if data.entity_type == "method" {
|
||||
data.body = Formatter.format(data.body)
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### AI統合の準備
|
||||
```sql
|
||||
-- ベクトル埋め込み保存
|
||||
CREATE TABLE embeddings (
|
||||
id INTEGER PRIMARY KEY,
|
||||
entity_type TEXT,
|
||||
entity_id INTEGER,
|
||||
embedding BLOB, -- float配列をBLOBで保存
|
||||
model_version TEXT,
|
||||
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
|
||||
);
|
||||
|
||||
-- 類似性検索用の仮想テーブル（将来的にベクトル検索エンジンと統合）
|
||||
CREATE VIRTUAL TABLE vector_search USING vector_index(
|
||||
embedding FLOAT[768]
|
||||
);
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
これらの技術的考慮事項を踏まえて、段階的に実装を進めることで、
|
||||
安全で高性能なデータベース駆動開発環境を実現できるにゃ！
|
||||
51
src/backend/llvm/compiler/codegen/instructions/call.rs
Normal file
51
src/backend/llvm/compiler/codegen/instructions/call.rs
Normal file
@ -0,0 +1,51 @@
|
||||
use std::collections::HashMap;
|
||||
|
||||
use inkwell::values::{BasicValueEnum as BVE, FunctionValue};
|
||||
|
||||
use crate::backend::llvm::context::CodegenContext;
|
||||
use crate::mir::{function::MirFunction, ValueId};
|
||||
|
||||
/// Lower a direct Call where callee is provided as a const string ValueId in MIR14.
|
||||
///
|
||||
/// Requirements:
|
||||
/// - `const_strs`: mapping from ValueId to the string literal value within the same function.
|
||||
/// - `llvm_funcs`: predeclared LLVM functions keyed by MIR function name (same string as const).
|
||||
pub(in super::super) fn lower_call<'ctx>(
|
||||
codegen: &CodegenContext<'ctx>,
|
||||
_func: &MirFunction,
|
||||
vmap: &mut HashMap<ValueId, BVE<'ctx>>,
|
||||
dst: &Option<ValueId>,
|
||||
callee: &ValueId,
|
||||
args: &[ValueId],
|
||||
const_strs: &HashMap<ValueId, String>,
|
||||
llvm_funcs: &HashMap<String, FunctionValue<'ctx>>,
|
||||
) -> Result<(), String> {
|
||||
let name_s = const_strs
|
||||
.get(callee)
|
||||
.ok_or_else(|| format!("call: callee value {} not a const string", callee.as_u32()))?;
|
||||
let target = llvm_funcs
|
||||
.get(name_s)
|
||||
.ok_or_else(|| format!("call: function not predeclared: {}", name_s))?;
|
||||
|
||||
// Collect args in order
|
||||
let mut avs: Vec<BVE<'ctx>> = Vec::with_capacity(args.len());
|
||||
for a in args {
|
||||
let v = *vmap
|
||||
.get(a)
|
||||
.ok_or_else(|| format!("call arg missing: {}", a.as_u32()))?;
|
||||
avs.push(v);
|
||||
}
|
||||
let params: Vec<inkwell::values::BasicMetadataValueEnum> =
|
||||
avs.iter().map(|v| (*v).into()).collect();
|
||||
let call = codegen
|
||||
.builder
|
||||
.build_call(*target, ¶ms, "call")
|
||||
.map_err(|e| e.to_string())?;
|
||||
if let Some(d) = dst {
|
||||
if let Some(rv) = call.try_as_basic_value().left() {
|
||||
vmap.insert(*d, rv);
|
||||
}
|
||||
}
|
||||
Ok(())
|
||||
}
|
||||
|
||||
@ -10,6 +10,7 @@ mod strings;
|
||||
mod arrays;
|
||||
mod maps;
|
||||
mod arith_ops;
|
||||
mod call;
|
||||
|
||||
pub(super) use blocks::{create_basic_blocks, precreate_phis};
|
||||
pub(super) use flow::{emit_branch, emit_jump, emit_return};
|
||||
@ -20,3 +21,4 @@ pub(super) use arith::lower_compare;
|
||||
pub(super) use mem::{lower_load, lower_store};
|
||||
pub(super) use consts::lower_const;
|
||||
pub(super) use arith_ops::{lower_binop, lower_unary};
|
||||
pub(super) use call::lower_call;
|
||||
|
||||
@ -242,30 +242,7 @@ impl LLVMCompiler {
|
||||
vmap.insert(*dst, bval);
|
||||
}
|
||||
MirInstruction::Call { dst, func: callee, args, .. } => {
|
||||
// Resolve callee name from const string -> lookup predeclared function
|
||||
let name_s = const_strs.get(callee).ok_or_else(|| format!("call: callee value {} not a const string", callee.as_u32()))?;
|
||||
let sym = format!("ny_f_{}", sanitize(name_s));
|
||||
let target = codegen
|
||||
.module
|
||||
.get_function(&sym)
|
||||
.ok_or_else(|| format!("call: function symbol not found: {}", sym))?;
|
||||
// Collect args
|
||||
let mut avs: Vec<BasicValueEnum> = Vec::new();
|
||||
for a in args {
|
||||
let v = *vmap
|
||||
.get(a)
|
||||
.ok_or_else(|| format!("call arg missing: {}", a.as_u32()))?;
|
||||
avs.push(v);
|
||||
}
|
||||
let call = codegen
|
||||
.builder
|
||||
.build_call(target, &avs.iter().map(|v| (*v).into()).collect::<Vec<_>>(), "call")
|
||||
.map_err(|e| e.to_string())?;
|
||||
if let Some(d) = dst {
|
||||
if let Some(rv) = call.try_as_basic_value().left() {
|
||||
vmap.insert(*d, rv);
|
||||
}
|
||||
}
|
||||
instructions::lower_call(&codegen, func, &mut vmap, dst, callee, args, &const_strs, &llvm_funcs)?;
|
||||
}
|
||||
MirInstruction::BoxCall {
|
||||
dst,
|
||||
|
||||
Reference in New Issue
Block a user