関数のイータ等価性はHaskellのseq操作と互換性がありますか?


14

補題:我々はそれを持っているETA-同等と仮定すると(\x -> ⊥) = ⊥ :: A -> B

証明:⊥ = (\x -> ⊥ x)イータ等価、および(\x -> ⊥ x) = (\x -> ⊥)ラムダの下での還元。

Haskell 2010レポートのセクション6.2では、seq2つの式で関数を指定しています。

seq :: a-> b-> b
seq⊥b =⊥
seq ab = b、a≠ifの場合

その後、「seqを使用してそれらを区別できるため、notは\ x-> beと同じではありません」と主張します。

私の質問は、それは本当にの定義の結果seqですか?

暗黙の引数は、seq計算できない場合seq (\x -> ⊥) b = ⊥です。しかし、私はそのようseqなものが計算できないことを証明することができませんでした。私にはそのようなa seqは単調で連続的であるように思われ、それは計算可能という領域にそれを置きます。

seqなどを実装するアルゴリズムは、starting で始まるドメインを列挙することxで、どこを検索しようとすることで機能する場合f x ≠ ⊥がありますf。そのような実装は、たとえ可能であっても、seq多態性を作りたいと思うとかなり毛深いものになります。

証拠は何も計算が存在しないことがあるseqことを識別(\x -> ⊥)して⊥ :: A -> B?または、その構造seqが特定され(\x -> ⊥)てい⊥ :: A -> Bますか?

回答:


6

最初に、とseq区別する方法を明示します:λx.

bottom :: a
bottom = bottom

eta :: a -> b
eta x = bottom

-- This terminates
fortytwo = seq eta 42

-- This does not terminate
infinity = seq bottom 42

したがって、Haskellのおよびでは実験的な事実ですは操作上区別できます。また、Haskellが計算するため、計算可能であることは事実であり、非常に明白です。Haskellについては以上です。あなたはHaskellのドキュメントの非常に特定のフレージングについて尋ねています。私はそれが2つの与えられた方程式を満たすはずであると言っていると読みましたが、それらの2つの方程式はの定義には十分ではありません。私はあなたに(単に入力された)の2機種与えることができます:理由はここにあるいる-calculus 計算を満たす与えられた方程式が、モデルの一つであるとλx.seqseqseqλseqλx. 同意しますが、他では同意しません。

式が連続関数のドメインで解釈される単純なドメイン理論モデル、、明らかに。効果的なScottドメインなどを使用して、すべてを計算可能にします。そのようなモデルで定義するのは簡単です。λ[DE]=λバツseq

我々はまたのモデルができ -calculusで区別λ xと、そしてもちろんη -ruleは成り立ちません。例えば、我々は、ドメイン内の関数を解釈することによってこれを行うことができます[ D E ] 、すなわち、余分の下で関数空間ドメインが付属します。今、ウェルの底部である[ D E ] ながら、λ X それ以上の要素があります。これらは両方とも評価されるため、アプリケーションで区別できませんλseqλバツη[DE][DE]λバツ、それらを何に適用しても(それらは拡張的に等しい)。しかし、ドメイン間のマップとして、ボトムを他のすべての要素と区別することが常にあります。seq


1
GHCやHugs gsおよびλx.⊥では実験的な事実です。幸いなことに、Haskellは実装によって定義されていません。私の質問は、Haskellがseqに関して不十分に指定されていることを示唆しています。
ラッセルオコナー

「効果的なスコットドメイン」とは、おそらく部分的な順序が決定可能であることを意味するものではありません。また、STLCはポリモーフィックではありませんが、Haskellはポリモーフィックです。通常、HaskellはSystem Fまたはその派生物の1つで解釈されます。これはあなたの議論にどのように影響しますか?
ラッセルオコナー

私の博士号のセクション1.1.4 dissertation andrej.com/thesis/thesis.pdfには効果的なスコットドメインの短い定義があり、これは実際に無料で利用できる最初のGoogleヒットです。
アンドレイバウアー

2
私のために証明を書くと、η-ruleが保持するHaskell 98の実装が得られ、(folder(\ ab-> fab)z xs)を(folder fz xs)に最適化して、Oからの漸近的なパフォーマンスの向上をもたらします(n ^ 2)からO(n)(ghc.haskell.org/trac/ghc/ticket/7436を参照)。さらに説得力のあることは、(NewTypeWrapper。f)のNewTypeWrapperを、強制的にfをイータ拡張せずに最適化し、GHCのnewTypesによって現在課されている漸近的なパフォーマンスペナルティを防止することです(foldrの使用など)。
ラッセルオコナー

1
λバツλバツseqseq

2

seq引用する仕様その定義ではないことに注意してください。Haskellのレポートを引用すると、「関数seqは方程式によって定義されます:[そして、与えられた方程式]」。

提案された引数は、seq(\ x->⊥)b = ifの場合、seqは計算不可能であると思われます。

そのような行動はの仕様に違反するでしょうseq

重要なのは、seqポリモーフィックでseqあるため、2つのパラメーターのいずれかでデコンストラクター(投影/パターンマッチングなど)の観点から定義できないことです。

\ :: A-> Bで(\ x->⊥)を識別する計算可能なseqがないという証拠はありますか?

の場合seq' (\x -> ⊥) b、最初のパラメーター(関数)を何らかの値に適用し、⊥を取得できると考えるかもしれません。しかし、パラメータの多相型のためseq、関数値で最初のパラメータを特定することはできません(たとえそれがたまたま使用された場合でもseq)。パラメトリック性とは、パラメーターについて何も知らないことを意味します。さらに、seq決して表現を取って「これは⊥ですか?」(停止問題を参照)、seqそれを評価しようとするだけで、それ自体は⊥に分岐します。

seqして第2のパラメータを返し、その後、最初のパラメータ(ではない、完全にはなく、「弱い頭正規形」[1]、すなわちに最上位のコンストラクタに)を評価することです。最初のパラメータがあることを起こる場合、それが原因と評価(すなわち、非終端計算)seqに非終了、ひいてはseq ⊥ a = ⊥

[1] seqが存在する場合の自由定理-Johann、Voigtlander http://www.iai.uni-bonn.de/~jv/p76-voigtlaender.pdf


seqに指定する仕様はseqの定義です。これは、セクション6.2でHaskell 2010レポートが正確に述べていることです。seqの操作定義は、Haskell 2010レポートではサポートされていません。「head normal form」という単語は、まったく異なるコンテキストでレポートに1回だけ出現します。また、GHCが最初の引数の前に2番目の引数をseqに減らすことが多い、または厳密性アナライザーが静的ではないことを証明したため、最初の引数はまったく減らないという私の理解と矛盾しています。
ラッセルオコナー

パラメトリック性は、解体子を適用できないと直接言っているわけでも、関数値で最初のパラメーターを特定できないとも言っていません。不変点を含む多相ラムダ計算のすべてのparametercityは、seqが厳密な関数を吸収できること、またはより一般的にはseqを含む用語の特定の厳密な関係が保持できることを示しています。(\ x->⊥)≠を証明するためにパラメトリックが使用される可能性があることは認めます。⊥、しかし、私は厳密な証拠を見たいです。
ラッセルオコナー

関数f : forall a . a -> TT他の型がある場合)の場合、f適用する解体子がわからないため、解体子を最初の引数に適用できません。型に対して「ケース」を行うことはできません。私は上記の答えを改善しようとしました(seq頭の標準形への評価に関する情報を引用することを含む)。
ドルチャード

時間があれば、後で厳密な証明を試みることができます(レイノルズのスタイルで関係を使用することは良いアプローチかもしれません)。
ドルチャード

@ RussellO'Connor:seqの記述はそれらの動作と「矛盾」せず、単なる動作仕様です(動作は最終結果を変更しない最適化です)。
ブレイザーブレード14年

2

λバツλバツ

サムソン・アブラムスキーはこの問題をかなり前に検討し、「The Lazy Lambda Calculus」という論文を書きました。したがって、正式な定義が必要な場合は、ここで確認できます。


1
どうやら、これらの詳細は「Haskellカーネル」に脱糖することによってのみ定義されます。どこで定義されていますか?レポートは、秒で言います。1.2:「カーネルは正式に指定されていませんが、本質的には、わかりやすい表記のセマンティクスを備えたラムダ計算のわずかに糖化されたバリアントです。
ブレイザーブレード14年

Haskell 2010のレポートは、驚くべきことに同じことを言っています。
ブレイザーブレード14年

Abramskyへの参照をありがとう!私はそれを質問に答える方法を確認し、次の答えを思いつきました:cstheory.stackexchange.com/a/21732/989
Blaisorblade

2

λxを証明する。Ω‌≠Ωinはアブラムスキーが彼の怠zyなラムダ計算理論(彼の論文の 2ページ、すでにUday Reddyによって引用された)のために設定する目標の1つです。定義2.7の時点で、彼はそのeta-reductionλxを明示的に議論しています。M x→Mは一般に有効ではありませんが、Mがすべての環境で終了する場合は可能です。これは、Mが総関数でなければならないことを意味するのではなく、Mの評価が終了する必要があるということだけです(たとえば、ラムダに減らすことによって)。

あなたの質問は、実際的な懸念(パフォーマンス)によって動機付けられているようです。しかし、Haskellレポートは完全に明確ではないかもしれませんが、λxを等しくすることには疑問があります。⊥‌ ‌を使用すると、Haskellの便利な実装が生成されます。Haskell '98を実装するかどうかは議論の余地がありますが、発言を考えると、著者がそのように意図していたことは明らかです。

最後に、seqは任意の入力タイプの要素を生成する方法を教えてください。(QuickCheckがそのために任意の型クラスを定義していることは知っていますが、そのような制約をここに追加することは許可されていません)。これはパラメトリックに違反します。

更新:私はこの権利をなんとかすることができませんでした(私はHaskelにあまり流ではないからです)runST。これを修正するには、ネストされた領域が必要なようです。単一の参照セル(STモナド内)を使用して、このような任意の要素を保存し、後で読み取り、それらを普遍的に利用できるようにしました。パラメトリックbreak_parametricity性は、提案されたseqが生成する要素を回復できる一方で、以下を定義できないことを証明します(ボトムを返すこと、たとえばエラーを除く)。

import Control.Monad.ST
import Data.STRef
import Data.Maybe

produce_maybe_a :: Maybe a
produce_maybe_a = runST $ do { cell <- newSTRef Nothing; (\x -> writeSTRef cell (Just x) >> return x) `seq` (readSTRef cell) }

break_parametricity :: a
break_parametricity = fromJust produce_maybe_a

ここで必要なパラメトリック性の証明を形式化するのは少しあいまいですが、この非公式なパラメトリック性の使用はHaskellの標準です。しかし、私はデレク・ドレイアーの著作から、ここ数年で必要な理論がすぐに解決されることを学びました。

編集:

  • これらの拡張機能が必要なのか、それがMLに似た、命令型で型付けされていない言語用に研究されているのか、またはパラメトリック性の古典理論がHaskellをカバーするのかどうかもわかりません。
  • また、私は後にUday Reddyの作品に出会ったからという理由だけでDerek Dreyerに言及しました。「レイノルズの本質」からごく最近知りました。(私は本当に先月かそこらでパラメトリックに関する文献を読み始めただけです)。

(\x -> writeSTRef cell (Just x) >> return x)ランダム入力で評価しても、セルへの書き込みは実行されません。渡されるシーケンス化されたSTコマンドのみrunSTが実行されます。同様に、実行main = (putStrLn "Hello") `seq` (return ())してもディスプレイには何も印刷されません。
ラッセルオコナー14

@ RussellO'Connor、もちろんあなたは正しいです-seqには私たちが議論した振る舞いがないのでテストは難しいです。しかし、要素を生成することは、それ自体パラメトリック性を壊すと考えています。それを例証するために答えを修正してみます。
ブレイザーブレード14

答えを明らかに修正するには、runST領域をネストし、内側の領域の外側の領域のセルを使用する必要がありますが、これは許可されていません。
ブレイザーブレード14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.