137 lines
4.8 KiB
Markdown
137 lines
4.8 KiB
Markdown
|
# AI-Nyash Compact Notation Protocol (ANCP) - Gemini & Codex Analysis
|
|||
|
|
Date: 2025-08-29
|
|||
|
|
Topic: ANCP深層技術分析
|
|||
|
|
|
|||
|
|
## Geminiさんの分析
|
|||
|
|
|
|||
|
|
### 圧縮記法の設計改善点
|
|||
|
|
|
|||
|
|
**記号の衝突と曖昧性**
|
|||
|
|
- `$` や `@` は多くの言語で特別な意味を持つため、確認が必要
|
|||
|
|
- 字句解析器が記号と識別子を明確に分離できる設計が重要
|
|||
|
|
- 演算子前後の空白処理に注意（`return-1` → `r-1` の曖昧性）
|
|||
|
|
|
|||
|
|
**マッピングの体系化**
|
|||
|
|
- 型・オブジェクト操作系: `$` `&` `*`
|
|||
|
|
- 制御フロー系: `!` `?`
|
|||
|
|
- スコープ・可視性系: `@` `:`
|
|||
|
|
- カテゴリ別の一貫性が重要
|
|||
|
|
|
|||
|
|
### 他言語での類似事例
|
|||
|
|
|
|||
|
|
**成功例**
|
|||
|
|
1. **JavaScript Minification**: 変数名短縮、空白削除で劇的なサイズ削減
|
|||
|
|
2. **Protocol Buffers/MessagePack**: スキーマ共有でキー名をIDに置換
|
|||
|
|
3. **WebAssembly**: .wat（テキスト）⇔ .wasm（バイナリ）の双方向変換
|
|||
|
|
|
|||
|
|
**失敗例・注意点**
|
|||
|
|
- **APL/J/K言語**: 極度の記号化により「書き込み専用言語」と揶揄される
|
|||
|
|
- ANCPは「AI専用」と割り切ることでこの問題を回避
|
|||
|
|
|
|||
|
|
### AIの学習効率向上のための記号選択
|
|||
|
|
|
|||
|
|
**トークナイザの基本**
|
|||
|
|
- BPE (Byte Pair Encoding) による頻出文字列の1トークン化
|
|||
|
|
- 単一ASCII記号（`$` `@` `#` など）は1トークンになりやすい
|
|||
|
|
|
|||
|
|
**最適な記号の優先順位**
|
|||
|
|
1. 単一ASCII記号: 最も効率的
|
|||
|
|
2. 1文字アルファベット: 良い選択だが空白区切り推奨
|
|||
|
|
3. 避けるべき: Unicode記号（複数バイト消費）
|
|||
|
|
|
|||
|
|
**実践的検証方法**
|
|||
|
|
```python
|
|||
|
|
import tiktoken
|
|||
|
|
enc = tiktoken.get_encoding("cl100k_base")
|
|||
|
|
# トークン数の実測実験
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### パーサー統合の技術要点
|
|||
|
|
|
|||
|
|
- **字句解析器の拡張**: ANCP記号→予約語トークンへの変換ルール
|
|||
|
|
- **双方向性の保証**: ANCPジェネレータとPretty Printer
|
|||
|
|
- **エラー報告**: Source Map的な仕組みで元コード位置を保持
|
|||
|
|
|
|||
|
|
### 将来の拡張性確保
|
|||
|
|
|
|||
|
|
- **マッピングテーブルの外部化**: JSON/TOML設定ファイル
|
|||
|
|
- **記号枯渇への備え**: 2文字組み合わせルール（`$b`, `$f`）
|
|||
|
|
- **プロトコルバージョニング**: `ancp/1.0;` ヘッダー
|
|||
|
|
|
|||
|
|
## Codexさんの実装設計
|
|||
|
|
|
|||
|
|
### Lexer設計（Rust）
|
|||
|
|
|
|||
|
|
**Dialect検出**
|
|||
|
|
- 明示ヘッダ: `;ancp:1 nyash:0.5;`
|
|||
|
|
- 自動判別: ANCP記号ヒット率による判定
|
|||
|
|
|
|||
|
|
**Token統合**
|
|||
|
|
- `TokenKind` で統一（通常/ANCP記号は同じTokenKindへ）
|
|||
|
|
- `LosslessToken` 層でトリビア（空白・コメント）保持
|
|||
|
|
|
|||
|
|
**データ構造**
|
|||
|
|
```rust
|
|||
|
|
enum Dialect { Nyash, ANCP(Version) }
|
|||
|
|
struct Token {
|
|||
|
|
kind: TokenKind,
|
|||
|
|
span: Span,
|
|||
|
|
raw: RawLexemeId,
|
|||
|
|
leading: Trivia,
|
|||
|
|
trailing: Trivia
|
|||
|
|
}
|
|||
|
|
struct Transcoder {
|
|||
|
|
to_ancp,
|
|||
|
|
to_nyash,
|
|||
|
|
span_map: SpanMap
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 双方向変換のテスト戦略
|
|||
|
|
|
|||
|
|
1. **同値往復**: `decode(encode(src)) == src`
|
|||
|
|
2. **プロパティテスト**: proptestでランダム構文木往復
|
|||
|
|
3. **パーサー同値**: AST正規化後の同型性assert
|
|||
|
|
4. **差分回帰**: cargo instaでスナップショット
|
|||
|
|
5. **ファジング**: libFuzzer/AFLでクラッシュ監視
|
|||
|
|
6. **境界網羅**: 演算子隣接、Unicode識別子など
|
|||
|
|
|
|||
|
|
### デバッグ体験の維持
|
|||
|
|
|
|||
|
|
- **診断の二面表示**: エラーで両表記併記 `@f (fn)`
|
|||
|
|
- **IDE統合**: LSPでホバー相互表示、CodeLens
|
|||
|
|
- **条件付きダンプ**: `RUST_LOG=ancp=trace`
|
|||
|
|
- **最小侵襲**: パーサー以降はTokenKindベースで動作
|
|||
|
|
|
|||
|
|
### パフォーマンス最適化
|
|||
|
|
|
|||
|
|
- **静的マップ**: `phf` でO(1)ルックアップ
|
|||
|
|
- **ゼロコピー**: `&str` スライスと軽量Span
|
|||
|
|
- **トリビア表現**: `SmallVec<[TriviaPiece; 2]>`
|
|||
|
|
- **ストリーミング**: 大規模ファイル対応
|
|||
|
|
|
|||
|
|
### AIファインチューニング戦略
|
|||
|
|
|
|||
|
|
- **並列コーパス**: (Nyash, ANCP)対訳データ生成
|
|||
|
|
- **タスク定義**: 翻訳、完成補完、修正適用
|
|||
|
|
- **評価指標**: 往復一致率、パース成功率、トークン削減率
|
|||
|
|
- **プロンプト指針**: ヘッダーと記号表を冒頭に付与
|
|||
|
|
|
|||
|
|
### 実装計画
|
|||
|
|
|
|||
|
|
**P1**: 固定辞書でTranscoder作成
|
|||
|
|
**P2**: Lexer統合、AST同値テスト
|
|||
|
|
**P3**: ヘッダー検出、エラーマッピング
|
|||
|
|
**P4**: ベンチと辞書最適化
|
|||
|
|
**P5**: LSP/CLI統合
|
|||
|
|
|
|||
|
|
## 統合された知見
|
|||
|
|
|
|||
|
|
両先生の分析から、ANCPは単なる圧縮ツールではなく、AI時代のプログラミング言語インフラストラクチャとして設計すべきことが明確になりました。特に重要なのは：
|
|||
|
|
|
|||
|
|
1. **トークン効率の実測主義** - 理論より実測で最適化
|
|||
|
|
2. **双方向完全性の保証** - テスト駆動で信頼性確保
|
|||
|
|
3. **デバッグ体験の維持** - 人間にも配慮した設計
|
|||
|
|
4. **将来拡張性の確保** - バージョニングと外部設定
|
|||
|
|
|
|||
|
|
これらの知見をPhase 11での実装に活かします。
|