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/プラグインシステムの専門的観点から、アドバイスをお願いします。
|