動的型言語のふわふわ感

Hideyuki Tanaka @tanakh

静的型チェックをしないことが優れているわけではないですよ。

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

そのランタイムの型エラーというのは、動的型エラーなのですか？それともランタイムエラーなのですか？ RT @tanakh: 実際にRubyでは1+"hoge"はランタイムの型エラーになっているということを言っているのだけど…。

Hideyuki Tanaka @tanakh

@tomooda ランタイムのエラーが動的型エラーなんですよ・・・

Hideyuki Tanaka @tanakh

@sbwhitecap 型推論に依る”静的”型付けは静的型付けのバリエーションであって、中間ではないです。

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

とすると、http://j.mp/qjRAXp に挙げた通り、ゼロ除算や空リストの先頭要素など、他のランタイムエラーとの違いがどこにあるかが問題です。純粋な動的型付けでは本質的な差異はないと思います。 @tanakh: ランタイムのエラーが動的型エラーなんですよ・・・

Hideyuki Tanaka @tanakh

@sbwhitecap 型宣言ができる動的型付けはありうると思います。たとえば、PHPだと関数の引数の型をアノテート出来ますけど、静的型はつかずランタイムの型検査コードが挟まるだけです。これは静的型検査のメリットは享受できませんが、コードの最適化などには有用でしょうね。

Hideyuki Tanaka @tanakh

@tomooda それを言ったらランタイムに構文エラーを吐くこともできるし、構文エラーと他のエラーの違いはという話にもなります。ランタイムに生成しているのが型エラーである以上、それをランタイムに検出するか、コンパイルタイムに検出するのかという話になるはずです。

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

この前提が議論の対象だということです。静的型付けでは型エラーとして扱われるでしょうね。で、動的型付けでもこれは型エラーなのですか？私はそうは思いません。空リストの先頭要素が型エラーでないのと同程度に。 RT @tanakh: ランタイムに生成しているのが型エラーである以上、

Hideyuki Tanaka @tanakh

@tomooda 実際型エラーにしてるものがあるんですからそれは型エラーなんでしょう・・・

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

つまり、型エラーだという根拠は、Rubyという特定の言語が定義している例外の名称、ということですか？ RT @tanakh: 実際型エラーにしてるものがあるんですからそれは型エラーなんでしょう・・・

Hideyuki Tanaka @tanakh

@tomooda Rubyという特定の動的型付け言語の処理系は少なくともランタイムに型エラーを出しますし、Pythonもそういうのはありますし、Schemeにもありますし、むしろなぜそのことに疑問を持たれるのでしょう？

Hideyuki Tanaka @tanakh

というか、ある演算を型エラーにするか否かってのは、型付けが静的か動的かは関係なくて、型付け自体をどうするかの問題じゃないですか・・・。

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

それらの動的型付け言語が用意しているTypeError例外は、静的型付け言語の動的型エラーと本当に同じモノでしょうか？単なるアナロジーで、静的型的な振舞いを動的型付け言語の枠組みでシミュレートしているだけでは？ RT @tanakh: 少なくともランタイムに型エラーを出しますし

Hideyuki Tanaka @tanakh

@tomooda シミュレートしているだけでしょう。シミュレートしているなら、同じことを達成しようとしているのではないのですか？

Hideyuki Tanaka @tanakh

たとえば、PHPが1+"hoge"で型エラーにならないのは、それが動的型付けだからなのではなくて、そういうtyping ruleだからでしょ。

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

動的型付け言語では型エラーをシミュレートしているだけなので、シミュレートしない、という選択肢が残されます。また、例外で実装している場合には、例外処理という選択肢も残されます。 RT @tanakh: シミュレートしているなら、同じことを達成しようとしているのではないのですか？

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

.@tanakh まあ例外処理でハンドル可能というのは、動的型付けだからこそ可能、というわけではないです。静的型付け言語の動的型検査の失敗が例外で通知される場合も同様ですね。

Hideyuki Tanaka @tanakh

@tomooda それはそうだと思いますが、基本的に型エラーはプログラムのエラーであるケースが殆んどですので、実際にはそういうことをしないという選択がなされているのではないのでしょうか？

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

たぶん方向性としては、静的型付けでは「できないことを引き受けない」ことを目指していて、動的型付けでのTypeError例外は「ごめん、これは扱えない。俺の力量不足です。」という泣きを入れるのと同義です。 RT @tanakh: 同じことを達成しようとしているのではないのですか？

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

どうしても扱えない時、渡した奴のエラーなのか、受けた奴の力不足なのか、渡された値がヘタレなのか、それが問題です。渡された値が頑張って、渡した奴や受けた奴の期待に答えてもＯＫなのです。 RT @tanakh: 基本的に型エラーはプログラムのエラーであるケースが殆んどですので、

しろくろきつね @skn9x

@tomooda 動的型付け言語にも型はあります。なにせ「動的に型付けする」言語ですから。型無し言語とも静的型付け言語とも違うせかいが♪そこにあります。

しろくろきつね @skn9x

@tomooda 言語設計者としては「実行時、+演算子で数値型以外の値を加算しようとした場合は、型エラー(実行時例外)とする」のように、もう自分で好きなように決める世界。

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

型といっても歴史的経緯から色々な種類の「型」があって、GCや処理系が管理する型や、抽象的な値の集合としての型や、インターフェイスを規定する型や、世界の構造をつくる型など、実に多相ですね。RT @skn9x: 動的型付け言語にも型はあります。なにせ「動的に型付けする」言語ですから。

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

一番大事なのは、プログラマやユーザが認知する単位としての型だと思っています。逆に言うと、計算機システムのユーザが型というものを認知しないのであれば、型は必要悪だとも思っています。 RT @skn9x: 動的型付け言語にも型はあります。なにせ「動的に型付けする」言語ですから。

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

とりあえず、静的に型整合が確認されていないと不安、というのは理解できる。でもその一方で有限桁な数値型は普通に使っちゃうのは理解できない。どちらも型に起因した「期待していない値」の問題なのに。