強制変換を推論するには？

Question

型推論の際に変換を推論する方法（暗黙の変換など）を知りたい。私はBastiaan HeerenのTop Quality Type Error Messagesで説明されている型推論スキームを使用していますが、一般的な考えはすべてのHindley-Milner-esqueアプローチではおそらく同じであると仮定します。

強制的な処理は過負荷の一種として扱うことができますが、この文書で説明されている過負荷の手法では、文脈が返す要求に基づいて（少なくとも私が従うことはできない方法で）型、それは強制的に必要です。私はまた、そのようなアプローチがアイデンティティ強制を優先させ、強制力の過渡的な閉鎖を尊重することを困難にするかもしれないと懸念している。 eのような強制的な表現がありますが、強制的に強制する（coerce（coerce（... coerce（... coerce（e）...）））強制的な入れ子の最大の入れ子までは、愚かなように見えるし、深さが文脈に依存しない有限の推移的閉包を持つものへの強制的な関係を制限する（不必要に制限する）。

Answer 1

あなたは何を求めているのか、もう少し詳しく説明できますか？

私はちょっと考えました。私の考えが正しいなら、この答えは私の答えとして十分であるはずです。言語を作成している人の観点から、これについて話していると思います。この場合、ActionScript 3のような言語を例に見ることができます。 AS3では、1）NewType（オブジェクト）、または2）というオブジェクトをNewTypeという2つの異なる方法で型キャストできます。

実装の観点からは、すべてのクラスをイメージングすることで、どのタイプにでも変換する独自の方法を定義する必要があります。に変換します（配列は実際に整数に変換できません...またはできますか？たとえば、Integer（myArrayObject）を試して、myArrayObjectでInteger型に変換する方法が定義されていない場合は、例外をスローするか、元のオブジェクトuncastedを渡すだけです。 :-D私は、これはあなたが

Answer 2

探しているものではない場合、私はあなたがこれまでいくつかの良い答えを得る願っています知ってみましょうけれども

私の全体の答えは完全にオフにすることができます。

リンク先の論文はまだ読んでいませんが、面白いと思います。ハスケルでのアドホックな多型（基本的にオーバーロード）がどのように機能するかを見てきましたか？ハスケルの型システムはH-Mといくつかの他の良いものです。それらのおいしさの1つはタイプクラスです。型クラスはオーバーロードを提供するか、またはHaskellerがそれをアドホック多型と呼びます。

最も広く使用されているHaskellコンパイラのGHCでは、型クラスは実行時に辞書を渡すことで実装されます。この辞書は、ランタイムシステムにタイプから実装へのルックアップをさせる。おそらく、jhcは、コンパイル時に適切な実装を選ぶのに超最適化を使うことができますが、私はHaskellが許すことができる完全な多型のケースを扱います。正式な証明や正当性を主張する論文は知りません。

あなたの型推論が他のランクn多型アプローチと同じ問題に遭遇するように思えます。追加の背景については、ここでいくつかの論文を読むことをお勧めします。Scroll down to "Papers about types"彼の論文は、haskell特有のものですが、タイプ理論的なものは意味を持ち、あなたにとって有益なはずです。

私はランクn個の多型と型チェックの問題については、この論文があなたのためにいくつかの興味深い思考を刺激すべきだと思う：http://research.microsoft.com/~simonpj/papers/higher-rank/

は私がより良い答えを提供することができますしたいです！がんばろう。

Answer 3

私の経験では、すべての用語を直感的に理解することは魅力的ではないようですが、追求する価値があります。

永続的記憶域への関心は、表現と原子値を混在させるという問題を検討するための迂回経路で私を導いてくれました。これをサポートするために、私は型システムで完全に分離することに決めました。したがって、Int、Charなどは、整数値と文字値の型コンストラクタです。式の型は、多態型のコンストラクタExpで形成されます。例えばExp Intは、あるステップでIntに減少する値を指します。

あなたの質問に対するこれの関連性は、評価を検討する際に発生します。基本的なレベルでは、原子値を必要とするプリミティブがあります：COND、addIntなどです。表現を強制するものとして、これを参照する人もいます。

これは明示的な削減指令を必要とせずにこれを実行できるかどうかを確認することです。 1つの解決策はあなたの提案とまったく同じです。つまり、強制を過負荷の一種として扱うことです。

たちは入力スクリプトを持って言う：foo x

その後、sugaring後、これは次のようになります。

coerce :: a -> b 
coerce x = REDUCE (cast x) if a and b are incompatible 
x       otherwise 

したがって強制が身元やアプリケーションのいずれかです：非公式、(coerce foo) (coerce x)

キャストここで、bは、特定のコンテキストの戻り値の型です。

キャストをタイプクラスメソッドとして扱うことができるようになりました。

class Cast a, b where {cast :: a -> b }; 
-- ¬:: is an operator, literally meaning: don’t cast 
--(!) is the reduction operator. Perform one stage of reduction. 

-- Reduce on demand 
instance Cast Exp c, c where { inline cast = ¬::(!)(\x::(Exp c) -> ¬::(!)x) }; 

¬::注釈が強制構文sugaringを抑制するために使用されます。

Castの他のインスタンスを導入してコンバージョンの範囲を広げることができますが、私はこれを検討していません。あなたが言うように、インスタンスが重なっている必要があります。