> ということは、コード/データの意味が実行時まで確定できない
> 状況というのがあれば、それは静的型付け/型安全な言語の
> 苦手な分野になるんじゃないか、と思いました。
> (考えて見れば当然ですが)。

はい、その通りです。が、単に、プログラマが意味を確定するかどうかというに
すぎないということが結構あります。つまり、確定できるかどうかというよりは
確定するかどうかというプログラミングスタイルの問題になっていることが
多いかもしれません。

> そういう状況のひとつの例として、こんなのはどうでしょう:
> 
> CommonLispでは標準化されていますが、Lispシステムでは
> 不正なデータが処理に入って来た時、処理を中断して
> ユーザにその状況を通知し、ユーザに代替となる値を生成する式を
> タイプさせて、それを評価した値を代わりに使って処理を
> 続行するということができます。
> 
> このメカニズム自身を静的型付け/型安全に書くことは可能でしょうか?
>
> (まあユーザインタラクションが発生する時点でIOモナドが
> ついてきちゃうという問題がひとつありますが、

Haskell では、あらかじめ、そのような修正入力ができるように、プログラマが
プログラムを書かなければできないとは思います。しかし、上の例なら、静的型付け
の言語で、原理的に難しいということはないと思います。

ユーザ入力は、外界からの入力なので、すべて文字列と看倣せますよね。それを
内部の型に変換して使うことになるので、その変換のための汎用 eval を予め用意で
きるかということになります。

Haskell ではどうするかというと、ユーザに入力をさせたい値の型を
あらかじめ、Read クラスのインスタンスとして宣言しておきます。

read <ユーザの入力文字列> と書いておくだけで、それが使われている文脈からの
推論で、型付けされて、その型が、Read クラスのインスタンスであれば、そのときの
ユーザ入力文字列が、その型の値に変換されます。この多相関数 read が LISP や
Ruby などの eval だと看倣せます。

> このシナリオのポイントは、ユーザがタイプした式をevalした
> 結果の型は実行時までわからないという点です。

つまり、eval (Haskell の場合 read) した結果の型は実は予めプログラマが
指定している、指定できることになります。つまりは、プログラマが型をつまり
プログラムの意味をあらかじめ決めているということです。

--nobsun


--
ML: haskell-jp / quickml.com
使い方: http://QuickML.com/