มีแนวคิดบางอย่างเช่นฟังก์ชั่น co-applicative ที่ทำงานระหว่าง comonads และ functors หรือไม่?


17

Monad ใด ๆ ก็เป็น functor สมัครและ functor สมัครใด ๆ ที่เป็น functor นอกจากนี้ comonad ใด ๆ ก็เป็นนักแสดง มีแนวคิดที่คล้ายกันระหว่าง comonads และ functors บางอย่างเช่น functor co-applicative และคุณสมบัติของมันคืออะไร?

functorsfunctorsฟังก์ชั่นการใช้งาน???monadsComonads

อัปเดต:ฉันยังสนใจที่จะใช้แนวคิดดังกล่าว


คุณแน่ใจหรือว่าไม่ต้องการ Comonads -> ??? -> ผู้ร่วมงาน?
josiah

1
@josiah ไม่เท่าที่ฉันรู้comonads เป็นหน้าที่ไม่ใช่ cofunctors
Petr Pudlák

1
ไม่สามารถแยกส่วนที่ขาดหายไปได้ใช่ไหม
กัส

คำตอบ:


15

ก่อนอื่น:

Monad ใด ๆ ก็เป็น functor สมัครและ functor สมัครใด ๆ ที่เป็น functor

นี่เป็นความจริงในบริบทของ Haskell แต่ (อ่านApplicativeว่า "strong lax monoidal functor") ไม่ใช่โดยทั่วไปด้วยเหตุผลเล็กน้อยที่คุณสามารถมีฟังก์ชั่น "applicative" ระหว่างหมวดหมู่ monoidal ต่าง ๆ ในขณะที่ monads (และ comonads) เป็น endofunctors .

นอกจากนี้การระบุApplicativeมีความแข็งแกร่ง functors หละหลวม monoidal เล็กน้อยทำให้เข้าใจผิดเพราะจะปรับชื่อ (และลายเซ็นประเภทของ(<*>)) ต้อง functor ระหว่างปิดประเภท monoidalซึ่งรักษาทั้งโครงสร้าง monoidalและหอมภายใน นี้ฟังอาจจะเรียกว่า "หละหลวมปิด functor monoidal" ยกเว้นว่า functor ระหว่างประเภทปิด monoidal ที่รักษาทั้งรักษาทรัพย์สินอื่น ๆ ในวิธีที่ชัดเจน เนื่องจากApplicativeอธิบายเฉพาะ endofunctors ในHask ที่รักษาโครงสร้าง monoidal ของ(,)มันอินสแตนซ์ของมันจะได้รับคุณสมบัติมากมายโดยอัตโนมัติรวมถึงความแข็งแรงของพวกเขาซึ่งทำให้สามารถถูกกำจัดได้

การเชื่อมต่อที่ชัดเจนด้วยMonadนั้นเป็นสิ่งประดิษฐ์ของข้อ จำกัด โดยนัยในการApplicativeก่อให้เกิดแง่มุมต่าง ๆ ของโครงสร้างโมโนโมนิคของพวกเขาที่จะเกิดขึ้นพร้อมกันซึ่งเป็นเรื่องบังเอิญที่มีความสุขซึ่งโชคไม่ดีที่ไม่รอด

เช่นเดียวกับ comonad ในหมวดหมู่นี้เป็น monad ในC o Pเป็นoplax monoidal functor C Dเป็นหละหลวม monoidal functor C o PD o P แต่โอพี DโอพีDโอพีHaskโอพีไม่ได้ปิดแบบ monoidal และสิ่งApplicativeที่ไม่รวมแอปพลิเคชันฟังก์ชันจะไม่ได้รับชื่อ อย่างไรก็ตามผลลัพธ์จะไม่น่าสนใจอย่างมาก:

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

เราสามารถจินตนาการถึงความคิดของ "colax Closed functor" ซึ่งจะมีลักษณะมากกว่านี้Applicativeถ้ามันมีอยู่จริง น่าเสียดายที่ไม่ได้ (ที่ดีที่สุดของความรู้ของฉัน) หมวดหมู่ที่ปิดทั้งหมด: ในH a s kสอดคล้องกับ morphisms b aในH a s k o pแต่ไม่ได้ทำงานเป็น หอมภายในมี - เพราะลูกศรจะกลับอะไรบางอย่างร่วมฟังก์ชั่นจะต้องแทนซึ่งเราไม่สามารถกำหนดโดยทั่วไปสำหรับH s kHaskโอพีnewtype Op b a = Op (a -> b)HaskaHaskโอพีOp b aHask

ถ้าเราแค่แกล้งทำเป็นว่า "colax Closed functors" มีไว้สำหรับและทำงานในแบบที่เราต้องการไร้เดียงสาหวังว่าพวกเขาจะเป็นเช่นนั้น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จะสร้าง comonad (โดยถือว่าเป็นที่น่าพอใจ) แต่ไม่มีความสัมพันธ์ที่ชัดเจนระหว่างcoap--whatever extend :: (f a -> b) -> f a -> f bมันอาจจะเป็น เปรียบเทียบประเภทมันจะกลายเป็นที่ชัดเจนว่า dualization ที่เกิดขึ้นในรูปแบบที่แตกต่างกัน: โครงสร้างพื้นฐาน comonoidal duplicateและcozipมีน้อยจะทำอย่างไรกับแต่ละอื่น ๆ หรือกับcoap(ซึ่งอาจจะไม่ได้ทำให้รู้สึกอยู่แล้ว) ในขณะที่liftA2 (,)และเทียบเท่าและสามารถนำมาจาก(<*>)join

อีกวิธีที่เป็นไปได้ของการทำให้เป็นคู่Applicativeซึ่งมีน้อยที่จะทำกับ comonads คือการพิจารณาฟังก์ชั่น monoidal contravariant:

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

แต่สิ่งนี้จะดำเนินไปในประเด็นเดียวกันกับที่กล่าวข้างต้นนั่นคือไม่ใช่หมวดหมู่ปิด ถ้าเป็นเราจะมีบางชนิดเช่นว่าเราสามารถเขียนฟังก์ชั่นเหมือนและและอื่น ๆ ที่ทำงานจริงตามที่คาดไว้Haskโอพีb <~ acontracurry :: (Either c b <~ a) -> (c <~ (b <~ a))contraapply :: b -> Either a (a <~ b)

HaskCoApplicative

อย่างไรก็ตามในหมวดหมู่ปิดแบบ monoidal มีอัธยาศัยดีกว่าคุณอาจโชคดีกว่า โดยเฉพาะอย่างยิ่งฉันเชื่อว่าทั้งสองอย่างKleisli (Cont r)และหมวดหมู่ที่ตรงข้ามนั้นปิดแบบ monoidal ดังนั้นจึงอาจเป็นบริบทที่ดีกว่าในการสำรวจแนวคิดเหล่านี้


เปรียบเทียบคำตอบของคุณกับcstheory.stackexchange.com/a/22302/989มันน่าประหลาดใจที่คุณไม่ทำให้ผลิตภัณฑ์เป็นสองเท่า แน่นอนว่าคุณถูกต้องที่ Hask ไม่มีผลรวมเด็ดขาด แต่ถ้าคุณยินดีที่จะ จำกัด หมวดหมู่ของโปรแกรมทั้งหมด (เช่นใน Agda) มาลองทำเป็นชุดสำหรับตอนนี้ปัญหานั้นจะหายไป (ฉันไม่ได้บอกว่า Set ^ op ปิดแบบ monoidal แต่ฉันสงสัยว่าสิ่งที่ฉันพูดหมายถึงมัน)
Blaisorblade

8

ในโพสต์นี้ในดังนั้นผมพบคำตอบที่น่าสนใจ - functors เด็ดขาด ถ้าเราเปลี่ยน()จากVoid, (,)โดยEither และย้อนกลับลูกศรที่เราได้รับ:

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

โพสต์บล็อกยังให้กฎหมายบางอย่างที่ functors เด็ดขาดเป็นไปตาม

และทุกคน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 

ดังนั้นฟังก์ชั่นเด็ดขาดเหมาะสมระหว่างฟังก์ชั่นและ comonads เช่นเดียวกับฟังก์ชั่นการใช้งานที่เหมาะสมในระหว่างฟังก์ชั่นและ monads


6

ไบรด์และแพตเตอร์สัน (มาตรา 7) แสดงให้เห็นว่า functor applicative ยังเป็นที่รู้จักในฐานะที่เป็นสำนวนเป็นที่แข็งแกร่ง functor คุณกำลังมองหาfunctor colax monoidal ที่แข็งแกร่งหรือที่รู้จักในฐานะoplax monoidal functor ที่แข็งแกร่ง ดังที่ได้กล่าวไว้ในความคิดเห็น oplax monoidal functor เป็น lax monoidal functor ระหว่างหมวดตรงข้ามซึ่งจบลงด้วยการเป็นเวอร์ชั่น comonoidal ของ lax monoidal functor

วาดไดอะแกรมกลับลูกศร!

ฉันต้องใช้เวลาสักครู่เพื่อหารายละเอียดเพื่อดูว่ามันคืออะไรและแปลมันเป็นแนวคิดการเขียนโปรแกรมที่ใช้งานได้


ด้วยเหตุผลบางอย่างคำศัพท์มาตรฐานดูเหมือนว่าจะเป็น "oplax monoidal functor" ความคิดนี้เป็นตัวละครประเภทหละหลวม lax monoidal ระหว่างหมวดตรงข้ามซึ่งจบลงด้วยการเป็นรุ่น comonoidal ของ functor lax monoidal การใช้ "colax comonoidal" นั้นซ้ำซ้อนหรือเทียบเท่ากับ "lax monoidal"
CA McCann

ฉันใช้คำว่า "ร่วม" มากเกินไป ฉันจะแก้ไขคำตอบของฉัน
Dave Clarke
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.