>>43
まず各LLにおける関数型プログラミングの適性度には大きな差異があること、
およびLLプログラミングではRubyしか深い経験/知識が(自分には)無いという理由から、
以降で述べる要望は「Rubyだけを対象」にしていることを断っておきます

最初の要望は、理想論であるけど「型推論を前提とした静的型付け」です
LLの主用途は(>>28で述べたように)日常的なテキスト処理であるけれど、
RailsやmRubyなどの登場によって「Rubyで製品を開発する」ケースが増えつつあります
この場合、生産性(効率的な開発)も大切ですが、長期間に渡って運用/開発が継続するという
性格から、品質(バグ発生率や保守性)が最も重要であると考えます
この高品質コード設計においては、生産性(簡潔さ)と高品質(安全性)を兼ね備えた
「型推論を前提とした静的型付け」がRubyに求められることになるでしょう

ただし、サブセットのRuby言語仕様であれば型推論の実験的実装について
いくつかの報告が存在しますが、完全なRuby言語仕様についてはかなり遠い目標でしょう
そこで、これに代わる現実論(=妥協案)として「省略可能な動的型検査構文」を要望したい
これは単純に def hoge(num : Integer, str : String) : MyClass といった構文でもいいし、
typexpr Integer * String -> MyClass のような明示的型式宣言でもいいし、
あるいはPythonのデコレータ記法を応用した型検査手法をパクってもいいと思います
なお、当たり前ですがこの要望は組み込み/標準添付ライブラリに関しても適用されるべきです

この要望は、ドキュメンテーションの改善にも役立てることができます
現在のRubyコミュニティでは、コメントとして記述された型情報を含む解説を抽出するという
JavaDocスタイルの文書化が主流です(たとえば「引数 num は整数、str は文字列 ......」)
ここで、もしも動的型検査構文が導入され、かつ型情報を外部へ出力できるようになれば、
そこからメソッドの型に関する解説を文書の一部として自動生成できるようになるはずです
また「コードとコメントの乖離」というJavaDocスタイル固有の問題(の一部)も解消されます

(続きは、また明日)