絞り込みタイプの推測


11

職場では、動的言語に関する型情報を推論する必要があります。次のように、ステートメントのシーケンスをネストされた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 g(f) {
  var x;
  x = f(3);
  return f(x);
}

これは次のように書き直されます。

\f.
  let x = undefined in
    let x = f 3 in
      f x

f:IntIntg:(IntInt)Int

g:τ1τ2.(Intτ1τ1τ2)τ2

オーバーロードされた+演算子のタイプを解決するために関数の依存関係をすでに使用しているので、それらを使用してf内のタイプを解決するのが自然な選択であると思いましたg。つまりf、すべてのアプリケーションののタイプが一緒になって、のタイプを一意に決定しgます。しかし、結局のところ、fundepsは、さまざまな数のソースタイプにあまり適していません。

とにかく、ポリモーフィズムと改良型付けの相互作用には問題があります。それで、私が見逃しているより良いアプローチはありますか?私は現在「MLの絞り込みタイプ」を消化しており、より多くの文献やその他の指針をいただければ幸いです。

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 

回答:


9

高次言語の静的不変量の推論は、理論的には決定不可能であることに加えて、実際には非常に難しいという事実に遭遇しました。あなたの質問に対する決定的な答えが何であるかはわかりませんが、いくつかの点に注意してください:

  • 先に述べたように、ポリモーフィズムタイプとリファインタイプは一緒にうまく動作しません。特に、最も一般的なタイプの概念は失われています。この結果、多型が存在する場合の絞り込みタイプに基づく分析では、プログラム全体の分析(構成分析ではなく)とヒューリスティックを使用してプログラムに割り当てるタイプを決定する必要がある場合があります。

  • 絞り込みタイプの推定と以下の間には強い関係があります。

    1. プログラムの抽象的な解釈の計算

    2. 命令型言語でのループ不変量の計算。

これを念頭に置いて、改良タイプの推論に関するいくつかのまとまりのない参照を以下に示します。絞り込みの種類にはさまざまな種類があることに注意してください。帰納的データ型の絞り込みに関心がある傾向があるため、このリストはその方​​向に偏っている場合があります。

  1. 古典から始めましょう:Cousot&Cousotによる高次関数型プログラムのRelational Abstract Interpretation。これは、リレーショナルセマンティクスを使用して抽象解釈を高次プログラムに拡張する方法を説明しています。

  2. Rhondon、Kawaguchi、Jhalaによる液体タイプ。これは非常に進化した作業であり、HMと一種の述語絞り込みを組み合わせて、MLスタイルプログラムのセキュリティアノテーション(たとえば、配列境界チェック)を推測します。推論は2つのステップで進行します。1つ目は、型注釈のHM推論で、実行する絞り込みの選択をガイドします。

  3. FF#

  4. ChinとKhooによる、特定の種類の絞り込みタイプ(サイズ注釈付きのタイプ)の推論に関する素晴らしい論文があります。

  5. ATSのプログラミング言語は、様々な改良を可能にし、彼らとプログラムを書くための機能を提供するシステムです。ただし、注釈は任意に複雑になる可能性があり(したがって、決定不可能)、ユーザーの操作が必要になる場合があります。これらのタイプには推論の形式があると思いますが、どの記事を推奨するべきかわかりません。

  6. 最後に重要なのは、Ole AgesenによるThe Cartesian Product Algorithmです。絞り込みの種類について明示的には言及していませんが、これはあなたが抱えていると思われる問題を解決するのに最も近い作業のようです。抽象でのパラメトリックな多態性の言及にだまされないでください。それらは、可能な原子型のタプルにすぎない具象型を推測するように見えます。効率性が重視されます。最初にこの記事を読んで、問題が解決するかどうかを確認することをお勧めします。

λ

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.