From: Nobuo Yamashita <nobsun / sampou.org>
Subject: [haskell-jp:247] Re: 低レベルプログラミングとstricttypesystem
Date: Sat, 01 Nov 2003 14:01:59 +0900 (JST)

> > Main> foo (2,3)
> > ERROR - Unresolved overloading
> > *** Type       : (Num a, Num b, FooArg (b,a)) => Int
> > *** Expression : foo (2,3)
> > 
> > むむむ。
> 
> あっとこれは、2 とか 3 が Int であることが推論できないからです。
> この場合は明示的に Int であることを教えてやる必要があります。

ああなるほど。わかりました。

議論を一段戻すと、もとのシナリオでは既存のコードに

  foo :: a -> b -> p

が存在するという場合に、それをインクリメンタルに改良してゆく
ことを話題にしているので、この方法による「名前の多重定義」は
使えないですね。

で、さらに議論スタックをもう一段popして、静的vs動的型付けの
話題に戻ります。プログラミングスタイル以外に差が出てくる
ケースはあるかを考えてみました。

このスレッドの最初に出た、「ランタイムが書けるか」の話で
インスパイアされたのですが、コード/データの意味を
そのコードを走らせる前に確定させることができれば、
静的型付け/型安全な言語と動的型付けな言語との本質的な差は
なさそうだと思えてきました。ランタイムの話題で言えば、
ランタイムライブラリとユーザプログラムが独立して意味を
検証できている限り、両方を静的型付け/型安全に書くことに
問題はなかったわけです。

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

そういう状況のひとつの例として、こんなのはどうでしょう:

CommonLispでは標準化されていますが、Lispシステムでは
不正なデータが処理に入って来た時、処理を中断して
ユーザにその状況を通知し、ユーザに代替となる値を生成する式を
タイプさせて、それを評価した値を代わりに使って処理を
続行するということができます。

このメカニズム自身を静的型付け/型安全に書くことは可能でしょうか?

(まあユーザインタラクションが発生する時点でIOモナドが
ついてきちゃうという問題がひとつありますが、
このシナリオのポイントは、ユーザがタイプした式をevalした
結果の型は実行時までわからないという点です。)

--shiro



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