75d09a89a8
- Create comprehensive type definitions for all future features - Adopt FFI ABI v0 compliance with platform-aware pointers (usize) - Implement 8-byte alignment for cross-platform compatibility - Design single entry point: nyash_plugin_invoke - Target Linux x86-64 for initial implementation - Use unimplemented!() for gradual feature addition Key decisions from AI review: - Pointer width: platform-dependent (not fixed 32-bit) - Early addition of Option/Result types - Clear ownership rules for strings/arrays - Extensible BoxHeader with magic number Phase 9.75g-0: Build it simple, make it work, then extend!
80 lines
3.2 KiB
Plaintext
80 lines
3.2 KiB
Plaintext
Nyashプログラミング言語のBID-FFI ABI v0統合計画について、最終レビューをお願いします。
|
||
|
||
【背景】
|
||
- Phase 9.75g BID（Box Interface Definition）が野心的すぎて複雑
|
||
- 既存のFFI ABI v0仕様はシンプルで実績がある
|
||
- 両者を統合し、段階的に実装可能な設計にしたい
|
||
|
||
【統合計画の要点】
|
||
|
||
1. **Phase 9.75g-0: FFI ABI v0準拠（1週間）**
|
||
- 型システム完全化：i32, i64, f32, f64, bool, string, array(T)
|
||
- メモリモデル明確化：32ビットポインタ、4バイトアライメント
|
||
- Effect system：pure/mut/io/controlの4種類
|
||
- Box layout標準化：[type_id:i32][ref_count:i32][field_count:i32]
|
||
|
||
2. **実装の簡素化戦略**
|
||
```rust
|
||
// Phase 1: C ABIのみ
|
||
pub enum TransportType {
|
||
DynamicLibrary, // 最初はこれだけ
|
||
#[allow(dead_code)]
|
||
Grpc, // Phase 2で追加
|
||
Rest, // Phase 2で追加
|
||
WasmComponent, // Phase 3で追加
|
||
}
|
||
```
|
||
|
||
3. **文字列・配列の統一表現**
|
||
```rust
|
||
// FFI ABI v0準拠
|
||
BidType::String => vec![WasmType::I32, WasmType::I32], // (ptr, len)
|
||
BidType::Array(_) => vec![WasmType::I32, WasmType::I32], // (ptr, len)
|
||
```
|
||
|
||
4. **段階的拡張パス**
|
||
- Phase 1: ローカルC ABI（.so/.dll）のみ
|
||
- Phase 2: ネットワーク対応（gRPC/REST）
|
||
- Phase 3: 言語ブリッジ（Python等）
|
||
- Phase 4: 未来技術対応（量子等）
|
||
|
||
【設計原則】
|
||
- **Simple First**: 動くものを最速で作る
|
||
- **FFI ABI v0互換**: 実績ある仕様に準拠
|
||
- **拡張可能**: TransportTypeで将来対応を予約
|
||
- **Everything is Box**: Nyash哲学を維持
|
||
|
||
【質問】
|
||
|
||
1. **FFI ABI v0準拠は適切か？**
|
||
- 型システムの統合方針は妥当か？
|
||
- メモリモデル（32ビット、4バイトアライメント）は現実的か？
|
||
- WASMとネイティブの両対応は可能か？
|
||
|
||
2. **段階的実装は現実的か？**
|
||
- Phase 1でC ABIのみに絞るのは賢明か？
|
||
- vtableを後回しにして基本型のみから始めるのは？
|
||
- 1週間でFFI ABI v0準拠は達成可能か？
|
||
|
||
3. **拡張性は確保されているか？**
|
||
- UniversalConnectorトレイトは将来のgRPC/REST対応に十分か？
|
||
- BidTypeは将来の複雑な型（Future/Stream等）に対応できるか？
|
||
- エラーモデルは異なるトランスポートに対応可能か？
|
||
|
||
4. **実装の落とし穴は？**
|
||
- 文字列の(ptr, len)表現で注意すべき点は？
|
||
- Box layoutのプラットフォーム依存性は？
|
||
- 既存のNyashコードとの互換性維持は？
|
||
|
||
5. **NyaMesh（P2Pライブラリ）との整合性**
|
||
- 将来P2P通信もBIDで統一できるか？
|
||
- TransportTypeにP2Pを追加する価値は？
|
||
- 場所透過性の設計は適切か？
|
||
|
||
【期待する成果】
|
||
- 1週間で動くC ABIプラグインシステム
|
||
- WASM/VM/LLVMすべてで同じBIDが使える
|
||
- 将来のネットワーク対応への明確な道筋
|
||
- Everything is Box哲学の技術的実現
|
||
|
||
実装者（Rust中級者）が理解でき、確実に動作し、将来拡張可能な設計になっているか、専門的観点からレビューをお願いします。 |