158 lines
5.1 KiB
Markdown
158 lines
5.1 KiB
Markdown
|
# 純粋関数型[]ブロック vs 通常{}ブロック設計案
|
|||
|
|
|
|||
|
|
## 概要
|
|||
|
|
|
|||
|
|
Nyashにおける**{}ローカルスコープ**と**[]純粋スコープ**の明確な差別化設計。
|
|||
|
|
「すべてはBox」哲学の中で、副作用を含む通常処理と純粋関数型処理を共存させる革命的アプローチ。
|
|||
|
|
|
|||
|
|
## 基本的な差別化
|
|||
|
|
|
|||
|
|
### {}ブロック（既存）- 通常のNyashスコープ
|
|||
|
|
```nyash
|
|||
|
|
{
|
|||
|
|
local counter = new IntegerBox(0) // Box生成OK
|
|||
|
|
counter.set(counter.get() + 1) // 副作用OK
|
|||
|
|
SomeGlobalBox.modify() // 外部状態変更OK
|
|||
|
|
ChannelBox.send("data") // I/O副作用OK
|
|||
|
|
// 普通のNyash文法、制約なし
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### []ブロック（提案）- 純粋関数型スコープ
|
|||
|
|
```nyash
|
|||
|
|
[
|
|||
|
|
// コンパイラが以下を厳密にチェック:
|
|||
|
|
input.map(x => x * 2) // ✅ 純粋変換のみ
|
|||
|
|
.filter(x => x > 10) // ✅ 副作用なし
|
|||
|
|
.reduce((a, b) => a + b, 0) // ✅ 参照透過性保証
|
|||
|
|
|
|||
|
|
// 以下はコンパイルエラー:
|
|||
|
|
// SomeBox.mutate() // ❌ 外部状態変更禁止
|
|||
|
|
// print("debug") // ❌ I/O副作用禁止
|
|||
|
|
// local x = 1; x = 2 // ❌ 変数再代入禁止
|
|||
|
|
]
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 深い差別化ポイント
|
|||
|
|
|
|||
|
|
### 1. コンパイラレベルの制約
|
|||
|
|
- **{}**: 制約なし、通常のNyash文法
|
|||
|
|
- **[]**: 厳密な純粋性チェック、副作用検出でコンパイルエラー
|
|||
|
|
|
|||
|
|
### 2. メモリモデル
|
|||
|
|
- **{}**: 新しいBoxの生成・変更可能
|
|||
|
|
- **[]**: 既存データの変換のみ、新しい状態作成禁止
|
|||
|
|
|
|||
|
|
### 3. 並行安全性
|
|||
|
|
- **{}**: データ競合の可能性あり
|
|||
|
|
- **[]**: 副作用なしなので自動的にthread-safe
|
|||
|
|
|
|||
|
|
### 4. 最適化
|
|||
|
|
- **{}**: 通常の最適化
|
|||
|
|
- **[]**: コンパイラが大胆な最適化可能（純粋性保証されているため）
|
|||
|
|
|
|||
|
|
### 5. デバッグ性
|
|||
|
|
- **{}**: 通常のデバッガ
|
|||
|
|
- **[]**: 入力→出力のみ追跡すればOK、デバッグ超簡単
|
|||
|
|
|
|||
|
|
## 実用的な使い分け例
|
|||
|
|
|
|||
|
|
```nyash
|
|||
|
|
box DataProcessor {
|
|||
|
|
processData(input: ArrayBox) -> ArrayBox {
|
|||
|
|
// 通常の{}スコープ: 準備・後処理
|
|||
|
|
{
|
|||
|
|
local logger = new LoggerBox()
|
|||
|
|
logger.info("Processing started")
|
|||
|
|
|
|||
|
|
// 純粋な[]スコープ: コア計算
|
|||
|
|
local result = [
|
|||
|
|
input
|
|||
|
|
.filter(x => x > 0)
|
|||
|
|
.map(x => Math.sqrt(x))
|
|||
|
|
.sort()
|
|||
|
|
]
|
|||
|
|
|
|||
|
|
logger.info("Processing completed")
|
|||
|
|
return result
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## []ブロックの真の価値
|
|||
|
|
|
|||
|
|
### 1. 数学的証明可能性
|
|||
|
|
[]内の処理は数学的に証明できる
|
|||
|
|
|
|||
|
|
### 2. 完全な再現性
|
|||
|
|
同じ入力→必ず同じ出力
|
|||
|
|
|
|||
|
|
### 3. 並列化自動最適化
|
|||
|
|
コンパイラが自動で並列化可能
|
|||
|
|
|
|||
|
|
### 4. ホットスワップ可能
|
|||
|
|
実行中でも[]部分だけ安全に入れ替え可能
|
|||
|
|
|
|||
|
|
## Box化による実装戦略
|
|||
|
|
|
|||
|
|
### PureCalculatorBox例
|
|||
|
|
```nyash
|
|||
|
|
box PureCalculatorBox {
|
|||
|
|
birth() { /* 状態なし、初期化も最小限 */ }
|
|||
|
|
|
|||
|
|
calculate(input: ArrayBox) -> ArrayBox {
|
|||
|
|
// []ブロックを使って、純粋性を言語レベルで保証
|
|||
|
|
local result = [
|
|||
|
|
input.map(x => x * 2).filter(x => x > 10)
|
|||
|
|
]
|
|||
|
|
return result
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### コンパイラもBox化
|
|||
|
|
「[]だけ解析する箱をつくる」アプローチ：
|
|||
|
|
- `PurityCheckerBox`: []ブロックの純粋性を厳密チェック
|
|||
|
|
- `ParserBox`: []専用構文解析
|
|||
|
|
- `OptimizerBox`: []専用最適化
|
|||
|
|
|
|||
|
|
## 哲学的統合
|
|||
|
|
|
|||
|
|
### {}ブロックと[]ブロックの共存
|
|||
|
|
- **{}**: "現実世界とのインターフェース"（副作用、状態管理）
|
|||
|
|
- **[]**: "純粋な計算の核心"（ロジック、変換、計算）
|
|||
|
|
|
|||
|
|
この差別化により、Nyashは：
|
|||
|
|
- **実用性** ({}での柔軟な状態管理)
|
|||
|
|
- **数学的美しさ** ([]での純粋性)
|
|||
|
|
|
|||
|
|
という**矛盾する要求を同時に満たす**ことができる。
|
|||
|
|
|
|||
|
|
## 「すべてはBox」哲学との整合性
|
|||
|
|
|
|||
|
|
これは「すべてはBox」哲学を破るのではなく、**異なる種類のBox（副作用Box vs 純粋Box）を明確に分離**する革命的なアプローチ。
|
|||
|
|
|
|||
|
|
- 副作用のあるBoxは{}内で使用
|
|||
|
|
- 純粋なBoxは[]内で使用
|
|||
|
|
- それぞれのBoxが適切なスコープで最大限の力を発揮
|
|||
|
|
|
|||
|
|
## 実装上の課題と解決策
|
|||
|
|
|
|||
|
|
### 課題
|
|||
|
|
1. コンパイラの複雑性増加
|
|||
|
|
2. []と{}間のデータやり取り
|
|||
|
|
3. エラーメッセージの分かりやすさ
|
|||
|
|
|
|||
|
|
### 解決策
|
|||
|
|
1. Box化されたコンパイラ（PurityCheckerBox等）で複雑性を分離
|
|||
|
|
2. 明確なデータ変換API（[]→{}は常に安全、{}→[]は純粋性チェック）
|
|||
|
|
3. 文脈に応じた専用エラーメッセージ
|
|||
|
|
|
|||
|
|
## 結論
|
|||
|
|
|
|||
|
|
この設計により、Nyashは純粋関数型プログラミングの利点を享受しつつ、実用的な副作用処理も自然に行える、世界初の「ハイブリッド純粋言語」となる可能性がある。
|
|||
|
|
|
|||
|
|
**Date**: 2025-09-22
|
|||
|
|
**Status**: アイデア段階
|
|||
|
|
**Priority**: Phase 16以降での検討推奨
|