静的型システムは、プロトタイプベースの言語の設計にどのように影響しますか？

プロトタイプベースの言語でWikipediaの記事は、次の段落が含まれています。

ほとんどすべてのプロトタイプベースのシステムは、インタープリター型および動的型付け言語に基づいています。ただし、静的に型付けされた言語に基づくシステムは技術的に実現可能です。

静的型システムは、どのように制限を課すか、プロトタイプベースの言語に複雑さをもたらしますか？そして、なぜ動的に型付けされたプロトタイプ言語があるのですか？

基本型とオブジェクトの境界はぼやけており、しばしば人為的に導入されています。たとえば、Cでは、構造体は単なるレコードの集まりであり、派生した非オブジェクト型です。C ++では、構造体はすべてのフィールドがpublicであるオブジェクトであるクラスです。それでも、C ++は、Cとほぼ完全に後方互換性があります...ここでは、境界線が本当にソフトです。

プロトタイプベースのプログラミングでは、実行時にオブジェクトを可変にする必要があります。実行時にそれぞれが変化し、ある種類のクラスが別の種類に変化するため、それらはソフトタイプでなければなりません。

ただし、基本および派生した非オブジェクト型を静的なままにしておくこともできます。しかし、これは奇妙な格差をもたらし、オブジェクトはソフトタイプであり、非オブジェクトは静的タイプであり、2つの間にハードバリアを確立する必要があります。構造をモーフィングできるはずですか？文字列？Numberはクラスまたは基本型、または基本型のセット、int / float / bignum / etcである必要がありますか？

このユニフォームを取得するための学習、使用、および書き込みは、より自然で簡単です。すべてのタイプが実行可能または実行時に変更できないタイプです。1つのタイプ（オブジェクト）のみが可変であると宣言すると、両方の世界で頭痛と問題が発生します。

静的型：

• 実装が簡単
• より速く/より効率的に
• より安全
• 抽象化により、大規模システムの保守/文書化が容易になります。

動的型付け：

• 書き込みが速く、
• より簡潔に
• 習得しやすい言語
• 設計エラーをより許容します。

2つをブレンドすることで、多くを犠牲にします。

• 実装は、前の2つのいずれよりも難しくなります。
• ソフトタイプを使用するかどうかによって速度は異なります。使用する場合、速度が遅く、使用しない場合、言語を選択する理由は何ですか。
• タイプセーフは、すべてのオブジェクトタイプの範囲外です。
• あるタイプが別のタイプにどのように変化するかを追跡することは、非常に難しいタスクです。それを文書化する-非常に難しい。
• あなたはまだ基本的なタイプですべての簿記を行う必要があります、それは簡潔さと書き込み速度を殺します
• 言語の複雑さは「特定の」言語の複雑さよりも高く（習得が難しい）、
• 動的型の「許容」は、属性型の不一致で非常にトリッキーなエラーが発生する傾向に置き換えられます。

難易度は非常に簡単です。オブジェクトをメソッドの辞書として、またはメッセージに応答するものとして見ると、一般的な静的型付けされたオブジェクト指向言語について以下を観察します。

• 通常、すべての辞書キー/メッセージは、静的に宣言された識別子を使用して事前に宣言されます。

• 特定のメッセージセットは事前に宣言され、オブジェクトはこれらのセットに関連付けられて、応答するメッセージを決定します。

• 別のサブセットであるメッセージセットの包含関係は、静的かつ明示的に宣言されます。宣言されていませんが、論理サブセットは無効です。

• 型チェックは、すべてのメッセージがそれらに応答するオブジェクトにのみ送信されることを保証しようとします。

これらはどれも、プロトタイプベースのシステムとある程度競合しています。

• メッセージ名は、事前に「原子」またはインターンされた文字列などの形式で宣言できますが、それ以外はほとんどありません。オブジェクトの可塑性は、メソッドへの型の割り当てが厄介であることを意味します。

• おそらく、メッセージのセットがオブジェクトの応答によって定義されるのは、他の方法ではなく、プロトタイプベースのシステムの本質的な機能です。コンパイル時にエイリアスを特定の組み合わせに割り当てることは妥当ですが、実行時に決定されたメッセージセットが可能でなければなりません。

• 上記の2つの本当の影響は、明示的な宣言が完全に実行不可能な包含関係に帰着します。静的な名目上のサブタイピングの意味での継承は、プロトタイプベースのシステムとは正反対です。

これで最終ポイントに到達しますが、実際には変更する必要はありません。それでも、メッセージはそれらに応答するオブジェクトにのみ送信されるようにします。しかしながら：

• グループ化されるメッセージを静的に知ることはできません。
• どのグループが他のグループのサブセットであるかを知ることはできません。
• どのグループ化が可能なのかわかりません。
• 単一のメッセージと共に送信される引数の種類を指定することもできません。
• 基本的に、完全に一般的なケースではほとんど何も指定できないことがわかりました。

では、これをどのように回避できますか？なんらかの方法で完全な一般性を制限する（これは不快で、そもそもプロトタイプベースのシステムを使用する利点をすぐに損なう可能性があります）か、型システムをより流動的にし、厳密な型ではなく制約を表現します。

制約ベースの型システムは、構造的サブタイピングの概念にすぐにつながります。これは、非常に緩やかな意味で、「アヒルタイピング」の静的な同等物と考えることができます。ここでの最大の障害は、そのようなシステムは型チェックがはるかに複雑であり、あまり知られていないということです（つまり、事前の研究がほとんどないことを意味します）。

要約すると、可能性としては、名目上の静的型システムまたはランタイムメタデータに基づく動的システムのいずれかよりも困難であるため、煩わしい人はほとんどいません。

静的に型付けされたプロトタイプベースの言語を実現する方法は、テンプレートと概念に基づいて言語を構築することだと思います。

概念はかつてC ++ 0xの計画された機能でした。C ++テンプレートの汎用コードは、すでに事実上「静的にアヒル型」になっています。Conceptsの考え方は、その関係の基礎となるクラス継承モデルを必要とすることも暗示することもなく、必要なメンバーと型の特性について何かを言うことができるということです（既に「静的に型付けされた」 ）。

Templates and Conceptsの基礎に基づいた言語では、プロトタイプベースのConceptになります。Templatesは、値のタイプを実装するために使用される場合とされない場合があるクラスモデルを気にする必要がありません。

段階的コンパイルを使用して言語を独自のメタ言語にするトリックを別にすれば、これらの概念のプロトタイプ派生物は、作成された後は必ず不変になります。ただし、プロトタイプベースではないという異議は、ニシンです。それは単に関数型言語になります。動的も機能しているプロトタイプベース言語は、少なくとも試みられています。