タグ付けされた質問 「type-inference」

1
依存型の型推論を決定できないのはなぜですか?
依存型システムは推論可能ではないが、確認可能であることを述べました。なぜそうなのか、また、型が値によってインデックス付けできる「依存性」の限界があるかどうか、それより下では型推論が可能で、それより上ではできないという簡単な説明があるのだろうかと思いました。

1
推論を決定できる最も強力な既知の型システムは何ですか?
Hindley-Milner型推論(多型を持つ単純に型付けされた -calculus)には決定可能な型推論があることはよく知られています:注釈なしでプログラムの基本型を再構築できます。λλ\lambda Haskellスタイルのタイプクラスを追加すると、この決定可能性が保持されるように見えますが、さらに追加すると、注釈のない推論が決定不能になります(タイプファミリー、GADT、依存タイプ、ランクNタイプ、システムなど)ωω\omega 私は疑問に思っています:完全に決定可能な推論を持つ最も強力な既知の型システムは何ですか?Hindley-Milner(完全に決定可能)と依存型(完全に決定不能)の間のどこかにあります。推論の決定可能性を保持する追加可能なDTの側面はありますか?これをどれだけプッシュできるかを調べるために、どのような研究が行われましたか? 単一の最強システムは存在せず、推論を維持しながらHMに追加できる無限の小さな増分的な変更が存在する可能性が高いことを認識しています。しかし、システムの実用的な候補がいくつか発見されている可能性があります。 編集:「最強の」システムがないことを考えると、決定可能な推論でHindley Milnerを拡張する注目すべきシステムの概要を示す回答を受け入れます。例としては、液体タイプ、ランク2などがあります。

1
Hindley-Milnerアルゴリズムがt1-> t2のような型を生成しないのはなぜですか?
私が読んだヒンドリー-ミルナータイピングアルゴリズムの実装を書いている間、あなたは常に引数は、最終的なタイプを決定する原子の種類やタイプのいずれかを取得します、限り、すべての変数がバインドされると、それを見る、などt1 -> t1か(t1 -> t2) -> (t1 -> t2)ここでt1およびt2は型変数です。 私はあなたのような何かを取得したい方法を考えることはできませんt1 -> t2か、単にt1私が表現の実際の型を判別する方法がないので、アルゴリズムが壊れている意味するであろう理解し、。すべての変数がバインドされている限り、これらの「壊れた」タイプのような型を決して取得しないことをどのように確認しますか? 私はアルゴリズムが変数を持つ型を生成することを知っていますが、関数に引数を渡すと、これらは常に解決されますが、typeを持つ関数ではそうではありませんt1 -> t2。これが、アルゴリズムがそのような型を決して生成しないことを確認する方法を知りたい理由です。 (MLでこれらの「壊れた」型を取得できるようですが、ラムダ計算について質問しています。)

3
タイプを推測することによる自動ダウンキャスト
Javaでは、変数をダウンキャストするために明示的にキャストする必要があります public class Fruit{} // parent class public class Apple extends Fruit{} // child class public static void main(String args[]) { // An implicit upcast Fruit parent = new Apple(); // An explicit downcast to Apple Apple child = (Apple)parent; } javaが型推論を行わないという事実を除いて、この要件には何らかの理由がありますか? 新しい言語で自動ダウンキャストを実装する際の「落とし穴」はありますか? 例えば: Apple child = parent; // no …

1
絞り込みタイプの推測
職場では、動的言語に関する型情報を推論する必要があります。次のように、ステートメントのシーケンスをネストされたlet式に書き換えます。 return x; Z => x var x; Z => let x = undefined in Z x = y; Z => let x = y in Z if x then T else F; Z => if x then { T; Z } else { F; Z } 一般的なタイプ情報から始めて、より具体的なタイプを推測しようとしているので、自然な選択は絞り込みタイプです。たとえば、条件演算子は、trueブランチとfalseブランチの型の和集合を返します。単純なケースでは、非常にうまく機能します。 ただし、次のタイプを推測しようとしたときに、思わぬ障害に遭遇しました。 function …
11 programming-languages  logic  type-theory  type-inference  machine-learning  data-mining  clustering  order-theory  reference-request  information-theory  entropy  algorithms  algorithm-analysis  space-complexity  lower-bounds  formal-languages  computability  formal-grammars  context-free  parsing  complexity-theory  time-complexity  terminology  turing-machines  nondeterminism  programming-languages  semantics  operational-semantics  complexity-theory  time-complexity  complexity-theory  reference-request  turing-machines  machine-models  simulation  graphs  probability-theory  data-structures  terminology  distributed-systems  hash-tables  history  terminology  programming-languages  meta-programming  terminology  formal-grammars  compilers  algorithms  search-algorithms  formal-languages  regular-languages  complexity-theory  satisfiability  sat-solvers  factoring  algorithms  randomized-algorithms  streaming-algorithm  in-place  algorithms  numerical-analysis  regular-languages  automata  finite-automata  regular-expressions  algorithms  data-structures  efficiency  coding-theory  algorithms  graph-theory  reference-request  education  books  formal-languages  context-free  proof-techniques  algorithms  graph-theory  greedy-algorithms  matroids  complexity-theory  graph-theory  np-complete  intuition  complexity-theory  np-complete  traveling-salesman  algorithms  graphs  probabilistic-algorithms  weighted-graphs  data-structures  time-complexity  priority-queues  computability  turing-machines  automata  pushdown-automata  algorithms  graphs  binary-trees  algorithms  algorithm-analysis  spanning-trees  terminology  asymptotics  landau-notation  algorithms  graph-theory  network-flow  terminology  computability  undecidability  rice-theorem  algorithms  data-structures  computational-geometry 

1
ML型推論の指数コストの簡潔な例
OCamlのような関数型言語での型推論のコストは非常に高くなる可能性があることに私の注意が向けられました。各式について、対応する型の長さが式の長さに対して指数関数的であるような一連の式があるという主張です。 以下のシーケンスを考案しました。私の質問は次のとおりです。同じ型を実現する、より簡潔な式のシーケンスを知っていますか? # fun a -> a;; - : 'a -> 'a = <fun> # fun b a -> b a;; - : ('a -> 'b) -> 'a -> 'b = <fun> # fun c b a -> c b (b a);; - : (('a -> 'b) -> 'b -> …

2
Hindley-Milner型システムのみを使用してリストを定義する
Hindley-Milner型推論システムが機能し、再帰的レッツ(リンクされたコードではない)もサポートする小さなラムダ計算コンパイラーに取り組んでいます。これは、チューリングを完全にするのに十分であることを理解しています。 問題は、リストをサポートする方法がわからない、またはすでにリストをサポートしているかどうかわからないこと、そしてそれらをエンコードする方法を見つける必要があることだけです。型システムに新しいルールを追加する必要なく、それらを定義できるようにしたいと思います。 私はリストの考えることができる最も簡単な方法xのいずれかであるものとしてあるnull(または空のリスト)、またはANの両方が含まペアxとのリストをx。しかし、これを行うには、ペアとorを定義できる必要があります。 このようにペアを定義できるようです: pair = λabf.fab first = λp.p(λab.a) second = λp.p(λab.b) 以来pairタイプを持つことになりa -> (b -> ((a -> (b -> x)) -> x))、通過した後、と言うintとstring、それはタイプで何かを得たい(int -> (string -> x)) -> xのペアの表現であろう、intとstring。ここで私が気になるのは、それがペアを表す場合、なぜそれが論理的に等価ではなく、命題を意味しないのint and stringかということです。ただし、と同等(((int and string) -> x) -> x)です。まるで、関数のパラメーターとして製品タイプしか持てないかのようです。この答えこの問題に対処しているようですが、彼が使用する記号の意味がわかりません。また、これが製品タイプを実際にエンコードしない場合、上記のペアの定義では実行できなかった製品タイプで実行できることはありますか(同じ方法でnタプルも定義できると考えて)?そうでない場合、これは含意のみを使用して(AFAIK)結合を表現できないという事実と矛盾しませんか? また、合計タイプはどうですか?関数タイプのみを使用してなんとかしてエンコードできますか?もしそうなら、これはリストを定義するのに十分でしょうか?それとも、タイプシステムを拡張せずにリストを定義する他の方法はありますか?そうでない場合、できる限りシンプルにしたい場合、どのような変更を加える必要がありますか? 私はコンピュータープログラマーですが、コンピューターサイエンティストでも数学者でもないので、数学の表記を読むのはかなり苦手です。 編集: これまでに実装したものの技術的な名前はわかりませんが、基本的には、上でリンクしたコードのみです。これは、アプリケーション、抽象化、変数のルールを使用する制約生成アルゴリズムですHinley-Milnerアルゴリズムから、次に主要な型を取得する統合アルゴリズムから。例えば、式は\a.aタイプが得られるa -> a、と表現は、\a.(a a)チェックエラーが発生したスローされます。これに加えて、letルールはありませんが、次の疑似コードのような再帰的なグローバル関数を定義できる同じ効果を持つように見える関数があります。 GetTypeOfGlobalFunction(term, globalScope, nameOfFunction) { // …

3
データフロー分析、抽象的な解釈、および型推論の同等性?
最近の質問に対する @Babouの回答は、データフロー分析の同等性(推論または証明できる事実と推論アルゴリズムを実行する時間の複雑さの両方の観点から)に関する論文を読んだことを思い出します、抽象解釈、および型推論。 一部のサブケース(フォワードコンテキスト依存の手続き間データフロー分析と抽象的な解釈の間など)では、同等性は私には比較的明白ですが、他の比較については問題がより微妙に思えます。たとえば、Hindley-Milner型推論を使用して、フロー依存のデータフロー分析で証明できるいくつかのプロパティを証明する方法を理解できません。 データフロー分析、抽象的な解釈、および型推論の間の同等性(または違い)について議論している独創的なリファレンスは何ですか?

2
型推論+オーバーロード
開発中の言語の型推論アルゴリズムを探していますが、通常は次のいずれかであるため、自分のニーズに合った型推論アルゴリズムを見つけることができませんでした。 アラモスHaskell、多態性はあるがアドホックなオーバーロードはない アラカルトC ++(自動)で、アドホックなオーバーロードはあるが、関数は単相 特に、私のタイプシステムは(簡素化)です(Haskellish構文を使用していますが、これは言語に依存しません)。 data Type = Int | Double | Matrix Type | Function Type Type そして、私はかなりのオーバーロードを持っている演算子*を持っています: Int -> Int -> Int (Function Int Int) -> Int -> Int Int -> (Function Int Int) -> (Function Int Int) (Function Int Int) -> (Function Int Int) -> (Function Int …

2
型チェックの決定可能性、入力可能性の決定可能性、および強い正規化の関係
ヨ!これはおそらくばかげた質問ですが、たとえば、型チェックの決定可能性が強力な正規化プロパティと同等である場合、明示的に書き留められたことはありません。したがって、私はこの質問をして、型チェック、型付け可能性、および強力な正規化の間のすべての可能な関係を明らかにします。 やる気を説明させてください。型理論(私はここでは意図的に曖昧にしていますが、主に依存型理論に興味があります)では、強い正規化を使用して型チェックの決定可能性を証明しています。反対に、これらのプロパティの1つを持っていることがわかっている型指定されたシステムには、もう1つのタイプもあります。ただし、強い正規化が型チェックの決定可能性に相当することを明示的に述べたことはありません。 同様に、タイプ可能性を証明するために、通常(多分常に)、用語を正規形に減らします。しかし、型付け可能性は依存型の理論には当てはまらないことはわかっていますが、強い正規化が保持される場合があります。 型チェックの決定可能性とは、特定の型、コンテキストおよび型なし項、がtrueでかどうかを有限数のステップで決定できることを意味します。ああAA Γ ⊢ A :AΓΓ\GammaaaaΓ ⊢ :AΓ⊢a:あ\Gamma \vdash a: A タイプ可能性の決定可能性と、特定の型なし用語、がtrueになるようなコンテキストとタイプが存在するかどうかを有限数のステップで決定できることを意味します。Γ A Γ ⊢ :AaaaΓΓ\GammaああAΓ ⊢ :AΓ⊢a:あ\Gamma \vdash a: A 1)型チェックの決定可能性は、すべての項が強く正規化可能であることと同じですか? 2)より一般的には、型チェックの決定可能性、タイプ可能性、強力な正規化の関係は何ですか?どちらが他を意味するのですか? 前もって感謝します。 編集 私の質問の一般性のレベル(私は知らなかった)に関する不満を考慮して、純粋なタイプシステムのみに限定したいと思います。もちろん、他のタイプ理論に関する追加のコメントや反例は非常に有用です。

1
タイプ割り当てシステム(TA)とHindley-Milnerシステムの関係
最近、型理論/型システムとラムダ計算の研究を始めました。 Church and Curryスタイルの単純型付きラムダ計算についてはすでに読みました。最後の1つは、タイプ割り当てシステム(TA)とも呼ばれます。 TAと、MLやHaskellのような言語のシステムであるHindley-Milner(HM)の関係について考えています。 ラムダ計算と結合子:はじめに(Hindley)の本は、TAは多態性であると述べています(ページ119)。それは、HMやSystem-Fなどのシステムでの多態性と同じ意味ですか? TAは強力な正規化特性を持つと言われているため、完全なチューリングではありません。HMシステムを使用する言語は、Haskellなどのように完全なものになりつつあります。したがって、HMシステムでは、無限ループような用語が型を受け取ることができるようになっている必要があります。それは正しいですか、それとも何か不足していますか?ΩΩ\Omega とにかくTAとHMの関係を知りたい。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.