क्या सह-आवेदक फंक्शनलर्स जैसे कॉमनर्स और फ़ंक्शनलर्स के बीच कुछ की अवधारणा है?

Question

कोई भी मोनाड एक आवेदक फ़नकार है और कोई भी आन्तरिक फ़नकार एक फ़नकार है। साथ ही, कोई भी कॉमनैड एक फनकार है। क्या कोमोनॉड्स और फंक्शनलर्स के बीच एक समान अवधारणा है, सह-आवेदक फ़ंक्टर की तरह कुछ है, और इसके गुण क्या हैं?

$$\begin{array}{c} \end{array}$$ $$\begin{array}{cc} \mbox{Functors} & & \mbox{Functors} \\ \uparrow & & \uparrow \\ \mbox{Applicative functors} & & ??? \\ \uparrow & & \uparrow \\ \mbox{Monads} & & \mbox{Comonads} \\ \end{array}$$

अद्यतन: मैं भी इस तरह की अवधारणा के संभावित उपयोगों में रुचि रखता हूं।

Comments

क्या आप सुनिश्चित हैं कि आप कोमोनॉड्स की तलाश में नहीं थे -> ??? -> Cofunctors?

— जोसिया

@ जोशियाह नो, जहां तक ​​मुझे पता है, कोमोनॉड्स फंक्शनलर्स हैं , कॉफनेक्टर नहीं।

— पेट्र पुडलक

नहीं है विभाज्य भाग लापता है कि?

— गस

Answer 1

सबसे पहले:

कोई भी मोनाड एक आवेदक फ़नकार है और कोई भी आन्तरिक फ़नकार एक फ़नकार है।

हास्केल के संदर्भ में यह सही है, लेकिन Applicativeसामान्य रूप से ( "मजबूत लक्स मोनॉयडल फ़ंक्टर" के रूप में पढ़ना ) सामान्य रूप से नहीं बल्कि इस कारण से है कि आपके पास अलग-अलग मोनोएडल श्रेणियों के बीच "आवेदक" फ़ंक्शंस हो सकते हैं, जबकि मोनाड (और कोमोनॉड्स) एंडोफुन्क्टर हैं ।

इसके अलावा, Applicativeमजबूत लैक्स मोनोएडल फंक्शनलर्स के साथ पहचान करना थोड़ा भ्रामक है, क्योंकि नाम को औचित्य देने के लिए (और प्रकार के हस्ताक्षर (<*>)) को बंद मोनोएडल श्रेणियों के बीच एक फ़ंक्टर की आवश्यकता होती है जो मोनोइडल संरचना और आंतरिक होम दोनों को संरक्षित करता है । इसे बहुतायत से एक "लैक्स क्लोज्ड मोनोएडल फंक्टर" कहा जा सकता है, सिवाय इसके कि मोनॉइडल क्लोज्ड श्रेणियों के बीच एक फंक्टर जो या तो संपत्ति को संरक्षित करता है, दूसरे को स्पष्ट तरीके से संरक्षित करता है । क्योंकि Applicativeहास्क पर केवल एंडोफुन्क्टरों का वर्णन करता है, जिसकी मोनोक्डल संरचना को संरक्षित करते हुए (,), इसके उदाहरण स्वचालित रूप से अपनी ताकत सहित बहुत सारे गुण प्राप्त करते हैं , जो कि इस तरह से बढ़ सकता है।

के साथ स्पष्ट रूप से संबंध स्पष्ट Monadरूप Applicativeसे संयोग की सीमाओं की एक कलाकृति है, जिससे संबंधित संबंधित संरचनाओं के संयोग बनते हैं, एक सुखद संयोग जो दुर्भाग्य से दोहरीकरण से नहीं बचता है।

जिस प्रकार एक श्रेणी पर कॉमनोड , C o p पर एक मोनाड है , एक oplax monoidal functor C → D एक lax monoidal functor C o p → D o p है । लेकिन एच एक रों कश्मीर ओ पी monoidal नहीं है बंद कर दिया , और एक सह जो ऐसा नहीं करता समारोह आवेदन शायद ही गुण नाम शामिल हैं। वैसे भी, परिणाम बहुत दिलचस्प नहीं होगा:$C$$C^{op}$ $C \rightarrow D$$C^{op} \rightarrow D^{op}$$\boldsymbol{Hask}^{op}$Applicative

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

हम इसके बजाय "कोलैक्स क्लोज्ड फ़ेक्टर" की धारणा की कल्पना कर सकते हैं, जो मौजूद होने पर बहुत अधिक लगेगा Applicative। दुर्भाग्य से, सब पर एक बंद श्रेणी (मेरी जानकारी के अनुसार करने के लिए) नहीं है: में एच एक रों कश्मीर morphisms से मेल खाती है ख → एक में एच एक रों कश्मीर ओ पी , लेकिन एक के रूप में काम नहीं करता है वहाँ आंतरिक Hom - क्योंकि तीर सह समारोह के कुछ प्रकार के बजाय की आवश्यकता होगी, जो हम के लिए सामान्य रूप में परिभाषित नहीं किया जा सकता उलट कर रहे हैं एच एक रों कश्मीर ।$\boldsymbol{Hask}^{op}$newtype Op b a = Op (a -> b)$\boldsymbol{Hask}$$b \rightarrow a$$\boldsymbol{Hask}^{op}$Op b a$\boldsymbol{Hask}$

हम बस यह है कि "colax बंद functors" नाटक तो लिए ही अस्तित्व में , और इसके अलावा जिस तरह से हम भोलेपन से आशा करता हूँ वे, एक सह में काम शायद इस प्रकार दिखाई देगा कि के आधार पर:$\boldsymbol{Hask}$Applicative

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। प्रकार यह स्पष्ट है कि dualization अलग अलग तरीकों से हो रहा है हो जाता है तुलना: comonoidal संरचनाओं अंतर्निहित duplicateऔर cozipथोड़ा एक दूसरे के साथ या साथ क्या करना है coap(जो शायद समझ में वैसे भी नहीं है), जबकि liftA2 (,)और (<*>)बराबर हैं और से प्राप्त किया जा सकता है join।

दोहरीकरण का एक और संभावित तरीका Applicative, जिसमें कॉमनॉड्स के साथ भी कम करना है, यह है कि कॉन्ट्रैविरिएंट मोनॉयडल फंक्शंस पर विचार करें:

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

लेकिन इसके बाद के संस्करण के रूप में ही मुद्दों के afoul इस रन, अर्थात् है कि एक बंद श्रेणी नहीं है। यदि यह थे, हम कुछ प्रकार होता है जैसे कि हम कार्यों लिख सकता है की तरह और और ताकि पर वास्तव में अपेक्षा के अनुरूप काम किया।$\boldsymbol{Hask}^{op}$b <~ acontracurry :: (Either c b <~ a) -> (c <~ (b <~ a))contraapply :: b -> Either a (a <~ b)

$\boldsymbol{Hask}$CoApplicative

हालांकि, एक monoidal बंद श्रेणी में दोहरीकरण के लिए अधिक मेहमाननवाज आप बेहतर भाग्य हो सकता है। विशेष रूप से, मेरा मानना ​​है कि दोनों Kleisli (Cont r)और इसकी विपरीत श्रेणी मोनॉयडल बंद है, ताकि इन विचारों का पता लगाने के लिए एक बेहतर संदर्भ हो सके।

Comments

Cstheory.stackexchange.com/a/22302/989 पर अपने उत्तर की तुलना करते हुए , यह आश्चर्यजनक है कि आप उत्पादों को डुबोना नहीं करते हैं। बेशक, आप सही कह रहे हैं कि हास्क में श्रेणीबद्ध रकम नहीं है; लेकिन अगर आप कुल कार्यक्रमों की श्रेणी (जैसे अगड़ा) में प्रतिबंधित करने के लिए तैयार हैं, तो आइए दिखाते हैं कि यह अभी के लिए सेट है, यह समस्या गायब हो जाती है। (मैं सेट नहीं कह रहा हूं ^ ऑप मोनॉयडल बंद है, लेकिन मुझे संदेह है कि मैं जो कह रहा हूं उसका तात्पर्य है)।

— Blaisorblade

Answer 2

में इतने पर इस पोस्ट - मैं एक दिलचस्प जवाब मिल गया निर्णायक functors । अगर हम बदलने के ()द्वारा Void, (,)द्वारा Either और तीर उल्टा, हम पाते हैं:

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

ब्लॉग पोस्ट कुछ ऐसे कानून भी देता है जो निर्णायक कार्य करने वालों का पालन करते हैं।

और, हर Comonadभी है Decisive:

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 

इसलिए निर्णायक फंक्शनल फंक्शंस और कॉमनॉड्स के बीच में फिट होते हैं, ठीक वैसे ही जैसे एप्लायनेटिव फंक्शंस फंक्शनल और मोनडैड्स के बीच फिट होते हैं।

Answer 3

मैकब्राइड और पैटरसन (धारा 7) से पता चलता है कि एक ऐप्लिकेटर फ़ंक्टर, जिसे एक आइडियल के रूप में भी जाना जाता है, एक मजबूत लैक्स मोनॉयडल फ़नकार है । आप एक मजबूत कोलैक्स मोनोएडल फन्क्टर की तलाश कर रहे हैं, जिसे एक मजबूत ऑप्लेक्स मोनॉयडल फंक्टर के रूप में भी जाना जाता है । जैसा कि एक टिप्पणी में उल्लेख किया गया है, एक ओपलैक्स मोनोइडल फ़ंक्टर विपरीत श्रेणियों के बीच एक लक्स मोनॉयडल फ़ंक्टर है, जो कि लैक्स मोनोइडल फ़ंक्टर का कोमनोइडल संस्करण होता है।

आरेख खींचें, तीर को उल्टा करें!

मुझे विवरण देखने के लिए थोड़ा समय बिताना होगा कि यह कौन सा है, और इसे एक कार्यात्मक प्रोग्रामिंग धारणा में अनुवाद करना है।

Comments

किसी कारण के लिए मानक शब्द "oplax monoidal functor" लगता है। विचार विपरीत श्रेणियों के बीच एक लक्ष्मण मोनोइडल फ़ंक्टर है, जो एक लक्स मोनोइडल फ़ंक्टर के कॉमोनोइडल संस्करण के रूप में समाप्त होता है। "कोलैक्स कोमोनाइडल" का उपयोग करना या तो बेमानी है या "लैक्स मोनॉयडल" के बराबर है।

— सीए मैककैन

मैं "सह" को ओवरडीड करता हूं। मैं अपना उत्तर ठीक करूंगा।

— डेव क्लार्क