氏が開発した漸進的型付けについての入門記事の翻訳です。導入された型アノテーションについて興味がある方は以下を参考にしてください。私自身、型システムに明るくないため、一部未訳の部分があったり、勘違いや誤訳もあると思います。いった誤りを見つけたら編集リクエストを送ってもらえると助かります。ともに開発した型システムです。するといったことを許容する型システムです。プログラマーは、どの部分から型アノテーションを除外するか、もしくは追加するかを制御します。本稿は漸進的型付けの優しい入門記事です。以下が漸進的型付けを開発する我々の動機でした:大規模なソフトウェアシステムは部分的に複数の言語で開発されることが多くなっています。これは動的型付け言語はある作業に向いていて、静的型付け言語はまた別の作業に向いているからです。漸進的型付けの型システムでは、プログラマーは静的型付けと動的型付けを選択できます。そこには別の言語に切り替えることや言語の相互運用性の痛みを伴うことはありません。願わくば、これがプログラマーの生産性を向上させるといいのにと思います。取り組みはほとんど行われていませんでした。漸進的型付けは、これらの言語がオプションの型アノテーションで何をするかについての基盤を提供することを意味します。いったオプションの型アノテーションを追加しようとしている新たな言語も開発中です。うまくいけば、我々の漸進的型付けの取り組みがこれらの言語に影響を与えるでしょう。漸進的型付けを説明する前に、動的型付けと静的型付けを見直してみましょう。動的型チェック人気のある言語のうちいくつか、特にスクリプト言語は動的型付けされる言語です。一連の共通操作をもつ値の集合を記述するようなものです。数の集合を記述します。誤った型の値に対する操作に適用されるものです。連結しようとするとある言語では型エラーが発生します。その言語では、連結は文字列のみが行える操作です。型エラーの別の例としては、あるオブジェクトのメソッドを呼び出すときに発生します。ように、そのオブジェクトが呼び出そうとするメソッドを実装していないときです。正確な定義はプログラミング言語次第です。ある言語は整数と文字列の連結を許容するのを選択していて、別の言語はそうではありません。動的型付け言語では、型チェックがプログラムの実行中に行われます。それはオペランド型がその操作にとって適切かを保証するためにそれぞれの操作を適用する直前に行います。インタープリターで上記のプログラムを実行すると次のように出力されます。インスタンスだとより具体的になれば、素晴らしいでしょう。いった言語が静的にチェックされる言語として人気があります。静的にチェックされる言語では、プログラムを実行する前に型チェッカーが一部もしくは全ての型エラーさえも捕捉します。通常、型チェッカーはコンパイラの一部であり、コンパイル時に自動的に実行されます。適用したプログラムを紹介します。コンパイラは、次のメッセージを出力します。error特定のプログラムが実行されるときに型エラーが発生することを型チェッカーがどう予測するかについて疑問に思う人もいるでしょう。その答えは予測できないということです。プログラムが型エラーを発生させるかさせないかを一般的に予測する型チェッカーを構築するのは不可能です。(これは既知の停止性問題に相当します。何かについてのエラーメッセージを伝えます。コンパイラは実際には型エラーを発生させないにも関わらず、次のプログラムを拒否します。文の分岐を把握しようとしません。その代わりに、保守的にどちらか一方の分岐先を通ると仮定し、それ故に両方の分岐先をチェックします。動的なチェックが優れていると思う人と静的型チェックが優れていると思う人との間で宗教戦争があります。この戦争があまりにも長い間行われている理由の1つは、両方のグループが良い点をもっているからだと私は考えています。(両方とも良くない点もいくつかあります。)残念ながら、一般的に2つのグループは他のグループがもつ良い点を良い点だと認めません。私の評価は以下の通りで、おそらく静的型付け支持者と動的型付け支持者のどちらも苛立たせるでしょう。これらはそれぞれの視点についての議論、または反論があります。以下の評価は私がその議論を検討した後で着地する場所を示します。静的型チェックは、事前にバグを捕捉します。それ故に開発サイクルの後でバグ修正する多くのコスト、またはその場所で起こる多くのバグのコストさえも取り除きます。動的型付けの支持者は、プログラムに対して徹底したテストスイートを作成することでより多くのバグを捕捉できると主張するでしょう。それでもなお、静的型チェックが型エラーを捕捉するために便利で低コストの方法を提供すると私は考えています。型チェッカーが受け入れるフォームへまずプログラムを変える必要がなく、そのプログラムをすぐに実行できます。型チェッカーにあうように変更することがそのプログラムをより良く構造化されたものにする、のどちらかを主張するでしょう。正しいと感じるプログラマーの理由は、使っている言語がプログラミングについての考え方を変えています。どんな言語を使っても型チェックしてプログラムを書くようそれとなく仕向けます。型システムのちょっと厄介なところを回避するのに慣れてしまいます。その型システムが厄介なものだというのを忘れて、代わりにその型システムを回避するノウハウに満足するようになります。関しては、その型システムが最も明確で再利用可能なフォームのコードを表現するのに邪魔になるという状況があります。型システムの研究が繁栄し続ける理由は、我々が書きたい全てのプログラムについて分かりやすく表せる、十分な表現力をもつ型システムを設計および実装することが困難だからです。静的型チェックは高速な実行を可能にします。それは実行時に型チェックを行う必要がなく、値がより効率の良い表現で格納されるからです。これは良い点です!動的型チェックは、値の型が実行時の情報に依存するといった状況に対応するのを簡単にします。これは良い点です!静的型付けはモジュール性を向上させます。動的言語だと、ライブラリのサブルーチンを不正に呼び出せますが、その後でそのルーチン内部の深いところで型エラーが発生します。静的チェックは、サブルーチンを呼び出したところで前もって型エラーを捕捉します。静的型チェックは、バグをさらに減らすのに役立つプログラムについてより真剣に考えさせます。型チェッカーはプログラムの単純なプロパティが適正であることのみをチェックします。プログラムが正しいことを保証する作業のほとんどは、静的型付けか動的型付けでチェックされる言語のどちらで記述されようと、包括的なテストを開発して検証します。動的型チェックを使用すると、型アノテーションを書く時間を費やす必要はありません。型アノテーションを記述するのにかかる時間は全く取るに足らないもので、型アノテーションを必要とせず型チェックできる型推論と呼ばれるプログラムがあります。静的型チェックと動的型チェックのどちらも一方が他方より普遍的に優れているとは言えないため、そういったパラダイムを強制せずプログラミング言語を切り替えるという選択肢をプログラマーに提供するのが理にかなっています。このことが漸進的型付けをもたらします。コンパイル時に型エラーを検出するためにプログラムを部分的にチェックしますが、他の部分はチェックしないといった型チェッカーです。それは型とともにアノテートされたプログラム部分により指示された通りにチェクします。向けの我々の漸進的型チェッカーのプロトタイプは、上記のプログラムのエラーを伝えません。以下に再び記述します。型アノテーションを追加するなら、型チェッカーはエラーを通知します。型で不整合があるからです。ようなローカル変数に対して静的な型を適用するための我々の規則は多少複雑です。ほとんどの場合は代入時の右辺の式と同じ型を変数に与えます。与えることにより、アノテートされていない変数を扱います。いう文字で省略します。演算子はその引数が整数であるのを期待すると仮定します。暗黙の変換を許容するからです。暗黙の変換を許容することは安全ではなく、漸進的型付けに動的型付けの特性を与えるものです。束縛されるその引数は加算が実行される前にそれが整数型だと保証するために実行時にチェックされます。暗黙の変換も許容します。次の呼び出を受け入れます。暗黙の変換を許容するからです。add1(3)漸進的型チェッカーは、より複雑な型同士の暗黙の変換も許容します。異なるタプル型間の変換があります。暗黙の変換を許容します。いう簡潔な表現を使います。2つの型が一貫性があるときに定義した規則をいくつか紹介します。