comonadsとfunctorの間にあるco-applicative functorのような概念はありますか?


17

モナドはすべて適用ファンクターであり、適用ファンクターはファンクターです。また、comonadはファンクターです。comonadsとファンクターの間に同様の概念がありますか?共同適用ファンクターのようなものがあり、その特性は何ですか?

ファンクターファンクター応用ファンクターモナドコモナド

更新:このような概念の可能な用途にも興味があります。


Comonadsを探していなかったと確信しています-> ??? ->コファンクター?
ジョサイア

1
@josiahいいえ、私が知っている限りでは、コマンドはファンクターであり、コファンクターではありません。
ペトルプドラク

1
その欠片は割り切れませんか?
ガス

回答:


15

まず第一に:

モナドはすべて適用ファンクターであり、適用ファンクターはファンクターです。

これはHaskellの文脈では当てはまりApplicativeますが、モナド(およびコナド)はエンドファンクターであるのに対し、異なるモノイダルカテゴリ間で「適用可能な」ファンクターを持つことができるというささいな理由で、一般的にはそうではありません(「強い緩いモノイダルファンクター」と読みます) 。

さらに、Applicative名前(およびの型シグネチャ(<*>))を正当化するためには、モノイド構造内部homの両方を保持する閉じたモノイドカテゴリ間でファンクターが必要になるため、強力な緩いモノイダルファンクターで識別することはわずかに誤解を招きます。これは、どちらかのプロパティを保持するモノイドの閉じたカテゴリー間のファンクターが明白な方法でもう一方を保持することを除いて、「緩い閉じたモノイドファンクター」ともっともらしい。ので上だけendofunctors説明Haskのmonoidal構造を維持し、そのインスタンスはその含め、自動的にプロパティの多くを獲得ので省略さすることができ、。Applicative(,)

との明らかな関係Monadは、おそらく、Applicativeそれぞれのモノイド構造の側面を一致させる暗黙の制限の成果物であり、残念ながら二重化を生き延びられない幸せな一致です。

カテゴリコモナがモナドであるように、oplaxのモニダルファンクタは、緩いモノイダルのファンクタです。しかし、はモノイダルではなく、関数適用を含まないco- は名前にほとんど値しません。とにかく、結果はそれほど面白くありません:CCop CDCopDopHaskopApplicative

class (Functor f) => CoMonoidal f where
    counit :: f () -> ()
    cozip :: f (a, b) -> (f a, f b)

代わりに、 "colax closed functor"の概念を想像できApplicativeます。これは、存在する場合のように見えます。残念ながら、でなく、すべてのクローズドカテゴリ(私の知る限り):で射に対応でただし、内部のホームとしては機能しません。矢印が逆になっているため、代わりに何らかの補助機能が必要になります。これはに対して一般的に定義できません。Haskopnewtype Op b a = Op (a -> b)HaskbaHaskopOp b aHask

oladsymbolに"colax閉じたファンクター"が存在し、さらにそれらが期待する方法で動作するように単純にふりをした場合、それに基づく共同ベースはおそらく次のようになります。HaskApplicative

class (Functor f) => CoApplicative f where
    copure :: f a -> a
    coap :: (f a -> f b) -> f (a -> b)

に追加duplicate :: f a -> f (f a)するcopureと、当然、(法律が満たされていると仮定して)コモナドが生成されます。しかし、coapそれが何であれ-との間に明らかな関係はありませんextend :: (f a -> b) -> f a -> f b。型を比較す​​ると、二重化がさまざまな方法で発生していることが明らかになります。基礎duplicateとなるコノノイド構造は互いにまたcozipはほとんど関係がありcoapません(おそらくおそらく意味をなさないでしょう)が、liftA2 (,)and (<*>)は同等であり、から派生することができますjoin

双対化のもう1つの可能な方法Applicativeは、コモナドとの関連性がさらに低いため、反変モニダルファンクターを考慮することです。

class (Contravariant f) => ContraMonoidal f where
    contraunit :: f a
    contrazip :: f a -> f b -> f (Either a b)

しかし、これは上記と同じ問題、つまりは閉じたカテゴリではないということです。それがあった場合、我々はいくつかのタイプだろうように我々は関数を書くことができるようにと、予想通りとなるように、実際に働いていたが。Haskopb <~ acontracurry :: (Either c b <~ a) -> (c <~ (b <~ a))contraapply :: b -> Either a (a <~ b)

記憶が私に役立つなら、ここでの障害はHaskellに特有のものではなく、むしろがデカルト閉である(もちろん通常の手を振るまで)ことから生じる。ほとんどの設定ではそれほど遠くないでしょう。HaskCoApplicative

ただし、双対化により適したモノイドの閉じたカテゴリでは、より良い運があります。特に、私はKleisli (Cont r)その両方とその反対のカテゴリーはモノイダル閉鎖であると信じているので、これらのアイデアを探求するためのより良いコンテキストかもしれません。


cstheory.stackexchange.com/a/22302/989への回答を比較すると、製品を合計に二重化しないのは驚くべきことです。もちろん、Haskにはカテゴリ合計はありません。しかし、プログラム全体のカテゴリ(Agdaなど)に制限したい場合は、今はSetのふりをしましょう、その問題は消えます。(Set ^ opがモノイド閉鎖であると言っているわけではありませんが、私が言っていることはそれを暗示していると思います)。
ブレイザーブレード

8

SOに関するこの投稿では、興味深い回答、つまり決定的なファンクターを見つけました。我々は交換した場合()Void(,)Either 矢印を逆に、我々が得ます:

class Functor f => Decisive f where
    nogood :: f Void -> Void
    orwell :: f (Either s t) -> Either (f s) (f t)

ブログの投稿には、決定的なファンクターが従ういくつかの法律も含まれています。

そして、すべてComonadDecisiveです:

instance Comonad c => Decisive c where
    nogood = counit
    orwell story = case counit story of
                     Left s  -> fmap (either id (const s)) story
                     Right t -> fmap (either (const t) id) story 

したがって、決定的なファンクターは、ファンクターとモナドの間に適合するファンクターと同じように、ファンクターとコマンドの間に収まります。


6

McBrideとPatterson(セクション7)は、イディオムとしても知られている適用ファンクターは、強力な緩いモノイダルファンクターであることを示しています。あなたは探している強いcolax monoidal数子としても知られている強力なoplax monoidal数子。コメントで述べたように、オプラックスモノイダルファンクターは、反対のカテゴリー間の緩いモノイダルファンクターであり、最終的には緩いモノイダルファンクターのコノノイドバージョンになります。

図を描き、矢印を逆にします!

それが何であるかを確認し、それを関数型プログラミングの概念に変換するために、私は少し時間をかけて詳細を練る必要がありました。


何らかの理由で、標準用語は「oplaxモノイダルファンクター」のようです。アイデアは、反対のカテゴリー間の緩いモノイダルファンクターであり、最終的には緩いモノイダルファンクターのコノノイドバージョンになります。「colax comonoidal」の使用は、冗長または「lax monoidal」と同等です。
CAマッキャン

私は「共同」をやり過ぎました。答えを修正します。
デイブクラーク
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.