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!
73 lines
2.7 KiB
Plaintext
73 lines
2.7 KiB
Plaintext
Nyashプログラミング言語のBID（Box Interface Definition）設計についてご相談です。
|
||
|
||
【背景】
|
||
Nyashは「Everything is Box」哲学のプログラミング言語で、現在Phase 9.75fでビルトインBoxの動的ライブラリ化とBID統合プラグインアーキテクチャを実装中です。
|
||
|
||
【現在の設計案】
|
||
1. 基本BID定義（YAML形式）
|
||
```yaml
|
||
version: 1
|
||
transport:
|
||
type: dynamic_library # 将来: grpc, rest, wasm, python_bridge等
|
||
location: ./libnyash_file.so
|
||
|
||
interfaces:
|
||
- name: nyash.file
|
||
box: FileBox
|
||
methods:
|
||
- name: open
|
||
params: [{string: path}, {string: mode}]
|
||
returns: handle
|
||
effect: io
|
||
```
|
||
|
||
2. 統一接続層（Rust実装）
|
||
```rust
|
||
trait UniversalConnector {
|
||
fn connect(&self, bid: &BidDefinition) -> Result<Connection>;
|
||
}
|
||
|
||
// 各種コネクター実装
|
||
struct DynamicLibraryConnector; // C ABI/.so
|
||
struct GrpcConnector; // リモートサービス
|
||
struct PythonBridgeConnector; // Python統合
|
||
```
|
||
|
||
3. 将来の接続先
|
||
- 他言語ライブラリ（Python/JS/Go/Java）
|
||
- リモートサービス（REST/GraphQL/gRPC）
|
||
- システムリソース（GPU/DB/MQ）
|
||
- 未来技術（量子コンピューター等）
|
||
|
||
【設計の狙い】
|
||
- Protocol Agnostic: トランスポート層を抽象化
|
||
- Location Transparent: ローカル/リモート透過的
|
||
- Future Proof: 新技術追加が容易
|
||
- Nyashコード不変: どんなバックエンドでも同じコード
|
||
|
||
【懸念点と質問】
|
||
1. **複雑性**: Transport抽象化は過度に複雑でしょうか？最初はC ABIのみに絞るべき？
|
||
|
||
2. **型システム**: MirValueでの統一は現実的？各バックエンドの型差異をどう吸収？
|
||
|
||
3. **性能**: 抽象化レイヤーのオーバーヘッドは許容範囲？特にタイトループでの呼び出し。
|
||
|
||
4. **エラー処理**: 異なるトランスポート（ローカル/ネットワーク）のエラーを統一的に扱える？
|
||
|
||
5. **段階的実装**: 以下の順序は妥当？
|
||
- Phase 1: C ABI動的ライブラリのみ
|
||
- Phase 2: REST/gRPC追加
|
||
- Phase 3: 言語ブリッジ（Python等）
|
||
- Phase 4: 汎用化
|
||
|
||
6. **既存システムとの比較**:
|
||
- WASM Component Model
|
||
- gRPC
|
||
- COM/CORBA
|
||
これらと比較してBIDの独自価値は？
|
||
|
||
7. **セキュリティ**: Capability-based securityは必要？それとも過剰設計？
|
||
|
||
実装者（Rust中級者）が理解・保守できる範囲で、将来の拡張性を確保する最適なバランスはどこでしょうか？
|
||
|
||
プログラミング言語設計とFFI/プラグインシステムの専門的観点から、アドバイスをお願いします。 |