109 lines
2.9 KiB
Plaintext
109 lines
2.9 KiB
Plaintext
Nyash言語のwhen構文と関数Box設計について深い相談です
|
||
|
||
【前回の議論からの進展】
|
||
|
||
1. when文採用でほぼ決定
|
||
- switch/caseより予約語が少ない
|
||
- 式としても使える
|
||
- パターンマッチングへの拡張性
|
||
|
||
2. => 構文の導入
|
||
- 現代的で見やすい
|
||
- 他言語（Rust, Kotlin, JS）でも採用
|
||
- 単一式とブロック両対応を検討中
|
||
|
||
3. returnキーワードは必須！
|
||
- 早期リターンに必要
|
||
- 明示性のため重要
|
||
- 式指向だけでは複雑になりすぎる
|
||
|
||
【新しい設計提案：fnによる関数Box】
|
||
|
||
通常のブロックと関数Boxを明示的に区別する案：
|
||
|
||
```nyash
|
||
// 通常のブロック（外側のスコープを共有）
|
||
when animal {
|
||
"dog" => {
|
||
me.count = me.count + 1 // 外側のBoxのme
|
||
local sound = "woof"
|
||
playSound(sound)
|
||
return sound // whenの値として返る
|
||
}
|
||
"cat" => meow() // 単一式もOK
|
||
else => silent()
|
||
}
|
||
|
||
// 関数Box（新しいスコープ、再帰可能）
|
||
when operation {
|
||
"factorial" => fn(n) {
|
||
if n <= 1 { return 1 }
|
||
return n * me(n - 1) // meは新しい関数Box自身！
|
||
}(5) // 即座に呼び出し
|
||
|
||
"counter" => fn() {
|
||
local count = 0
|
||
return {
|
||
increment: fn() { count = count + 1 },
|
||
get: fn() { return count }
|
||
}
|
||
}()
|
||
}
|
||
```
|
||
|
||
【質問事項】
|
||
|
||
1. when vs match
|
||
- whenという名前で良いか？
|
||
- matchの方が良い？
|
||
- 他の候補：check, on, select
|
||
|
||
2. => 構文の詳細設計
|
||
- 単一式：`"dog" => bark()`
|
||
- ブロック：`"dog" => { ... }`
|
||
- 関数Box：`"dog" => fn(args) { ... }`
|
||
- この3パターンで十分か？
|
||
|
||
3. fnキーワードの役割拡張
|
||
- 現在：関数定義のみ
|
||
- 提案：インライン関数Box作成にも使用
|
||
- 一貫性は保たれるか？
|
||
|
||
4. Everything is Box哲学との整合性
|
||
- {} だけでは通常のブロック（Boxではない）
|
||
- fn{} で関数Box
|
||
- この区別は哲学に反しないか？
|
||
|
||
5. 実装の観点
|
||
- MIR/VM/LLVMでの実装難易度
|
||
- 最適化の可能性
|
||
- デバッグのしやすさ
|
||
|
||
【設計原則の確認】
|
||
|
||
- 明示性：何が起きているか一目瞭然
|
||
- シンプルさ：初学者にも分かりやすい
|
||
- 表現力：実用的なプログラムが書ける
|
||
- 一貫性：言語全体で統一感がある
|
||
|
||
【予約語リスト（案）】
|
||
必須機能に必要な最小限：
|
||
1. box
|
||
2. new
|
||
3. me
|
||
4. public
|
||
5. if
|
||
6. else
|
||
7. loop
|
||
8. break
|
||
9. continue
|
||
10. when (またはmatch)
|
||
11. return
|
||
12. import
|
||
13. from
|
||
14. birth (コンストラクタ)
|
||
15. fn
|
||
|
||
予約語10個厳守ではなく、必要なものは追加する方針です。
|
||
|
||
プログラミング言語設計の観点から、この設計の妥当性と改善案をお聞かせください。 |