เหตุใดผลข้างเคียงที่จำลองเป็นพระใน Haskell

ใครบ้างให้คำแนะนำว่าทำไมการคำนวณที่ไม่บริสุทธิ์ใน Haskell ถูกจำลองเป็นพระ?

ฉันหมายถึง monad เป็นเพียงส่วนต่อประสานที่มี 4 การดำเนินการดังนั้นอะไรคือเหตุผลที่ทำให้เกิดผลข้างเคียงในการสร้างแบบจำลอง?

สมมติว่าฟังก์ชั่นมีผลข้างเคียง หากเราใช้เอฟเฟกต์ทั้งหมดที่สร้างขึ้นเป็นพารามิเตอร์อินพุทและเอาท์พุทฟังก์ชั่นนั้นบริสุทธิ์ต่อโลกภายนอก

ดังนั้นสำหรับฟังก์ชั่นที่ไม่บริสุทธิ์

f' :: Int -> Int

เราเพิ่ม RealWorld เข้ากับการพิจารณา

f :: Int -> RealWorld -> (Int, RealWorld)
-- input some states of the whole world,
-- modify the whole world because of the side effects,
-- then return the new world.

จากนั้นfบริสุทธิ์อีกครั้ง เรากำหนดประเภทข้อมูลแบบ Parametrized type IO a = RealWorld -> (a, RealWorld)ดังนั้นเราไม่จำเป็นต้องพิมพ์ RealWorld หลายครั้งและสามารถเขียนได้

f :: Int -> IO Int

สำหรับโปรแกรมเมอร์การจัดการ RealWorld โดยตรงนั้นอันตรายเกินไปโดยเฉพาะอย่างยิ่งหากโปรแกรมเมอร์ได้รับประโยชน์จากประเภทของ RealWorld พวกเขาอาจลองคัดลอกซึ่งเป็นไปไม่ได้ (ลองนึกถึงการพยายามที่จะคัดลอกทั้งระบบไฟล์ตัวอย่างคุณจะใส่มันไว้ที่ไหน) ดังนั้นคำจำกัดความของ IO ของเราจึงสรุปสภาวะของโลกทั้งโลกเช่นกัน

องค์ประกอบของฟังก์ชั่น "ไม่บริสุทธิ์"

ฟังก์ชั่นที่ไม่บริสุทธิ์เหล่านี้ไร้ประโยชน์ถ้าเราไม่สามารถโยงมันเข้าด้วยกัน พิจารณา

getLine     :: IO String            ~            RealWorld -> (String, RealWorld)
getContents :: String -> IO String  ~  String -> RealWorld -> (String, RealWorld)
putStrLn    :: String -> IO ()      ~  String -> RealWorld -> ((),     RealWorld)

เราต้องการ

• รับชื่อไฟล์จากคอนโซล
• อ่านไฟล์นั้นและ
• พิมพ์เนื้อหาของไฟล์นั้นไปยังคอนโซล

เราจะทำอย่างไรถ้าเราสามารถเข้าถึงรัฐในโลกแห่งความจริงได้?

printFile :: RealWorld -> ((), RealWorld)
printFile world0 = let (filename, world1) = getLine world0
                       (contents, world2) = (getContents filename) world1 
                   in  (putStrLn contents) world2 -- results in ((), world3)

เราเห็นรูปแบบที่นี่ ฟังก์ชั่นนี้เรียกว่า:

...
(<result-of-f>, worldY) = f               worldX
(<result-of-g>, worldZ) = g <result-of-f> worldY
...

ดังนั้นเราสามารถกำหนดโอเปอเรเตอร์~~~เพื่อผูกมัน:

(~~~) :: (IO b) -> (b -> IO c) -> IO c

(~~~) ::      (RealWorld -> (b,   RealWorld))
      ->                    (b -> RealWorld -> (c, RealWorld))
      ->      (RealWorld                    -> (c, RealWorld))
(f ~~~ g) worldX = let (resF, worldY) = f worldX
                   in g resF worldY

จากนั้นเราก็สามารถเขียน

printFile = getLine ~~~ getContents ~~~ putStrLn

โดยไม่ต้องสัมผัสโลกแห่งความจริง

"Impurification"

ตอนนี้สมมติว่าเราต้องการสร้างเนื้อหาไฟล์เป็นตัวพิมพ์ใหญ่เช่นกัน การพิมพ์ใหญ่เป็นหน้าที่บริสุทธิ์

upperCase :: String -> String

IO Stringแต่การที่จะทำให้มันกลายเป็นโลกแห่งความจริงก็มีการส่งคืน มันง่ายที่จะยกฟังก์ชั่นดังกล่าว:

impureUpperCase :: String -> RealWorld -> (String, RealWorld)
impureUpperCase str world = (upperCase str, world)

นี่สามารถสรุปได้:

impurify :: a -> IO a

impurify :: a -> RealWorld -> (a, RealWorld)
impurify a world = (a, world)

เพื่อให้impureUpperCase = impurify . upperCaseและเราสามารถเขียน

printUpperCaseFile = 
    getLine ~~~ getContents ~~~ (impurify . upperCase) ~~~ putStrLn

_{(หมายเหตุ: โดยปกติเราเขียนgetLine ~~~ getContents ~~~ (putStrLn . upperCase))}

เราทำงานกับ monads มาตลอด

ตอนนี้เรามาดูสิ่งที่เราทำ:

1. เราได้นิยามโอเปอเรเตอร์(~~~) :: IO b -> (b -> IO c) -> IO cที่เชื่อมโยงฟังก์ชันที่ไม่บริสุทธิ์สองอย่างเข้าด้วยกัน
2. เรากำหนดฟังก์ชันimpurify :: a -> IO aที่แปลงค่าบริสุทธิ์ให้ไม่บริสุทธิ์

ตอนนี้เราทำบัตรประจำตัว(>>=) = (~~~)และreturn = impurifyและดู? เรามี monad

หมายเหตุด้านเทคนิค

เพื่อให้แน่ใจว่าเป็น monad จริงๆยังมีสัจพจน์บางอย่างที่ต้องตรวจสอบด้วย:

1. return a >>= f = f a

    impurify a                =  (\world -> (a, world))
   (impurify a ~~~ f) worldX  =  let (resF, worldY) = (\world -> (a, world )) worldX 
                                 in f resF worldY
                              =  let (resF, worldY) =            (a, worldX)       
                                 in f resF worldY
                              =  f a worldX

2. f >>= return = f

   (f ~~~ impurify) worldX  =  let (resF, worldY) = f worldX 
                               in impurify resF worldY
                            =  let (resF, worldY) = f worldX      
                               in (resF, worldY)
                            =  f worldX

3. f >>= (\x -> g x >>= h) = (f >>= g) >>= h

   ทิ้งไว้เป็นการออกกำลังกาย

ใครบ้างให้คำแนะนำว่าทำไมการคำนวณแบบไม่บริสุทธิ์ใน Haskell ถูกจำลองเป็นพระ?

คำถามนี้มีความเข้าใจผิดอย่างกว้างขวาง มลทินและ Monad เป็นแนวคิดอิสระ สิ่งเจือปนไม่ได้เป็นแบบจำลองโดย Monad ค่อนข้างมีชนิดข้อมูลบางอย่างเช่นIOที่แสดงถึงการคำนวณที่จำเป็น และสำหรับบางประเภทนั้นเศษส่วนเล็ก ๆ ของอินเตอร์เฟสของพวกเขาสอดคล้องกับรูปแบบอินเตอร์เฟสที่เรียกว่า "Monad" นอกจากนี้ยังมีเป็นที่รู้จักกันไม่มีคำอธิบายที่บริสุทธิ์ / ทำงาน / denotative ของIO(และมีไม่น่าจะเป็นหนึ่งพิจารณา"บาปถัง"วัตถุประสงค์ของการIO) แม้ว่าจะมีเรื่องบอกกันทั่วไปเกี่ยวกับการเป็นความหมายของWorld -> (a, World) IO aเรื่องนั้นไม่สามารถอธิบายได้จริงIOเพราะIOรองรับการเกิดพร้อมกันและ nondeterminism เรื่องราวไม่ได้ทำงานแม้กระทั่งสำหรับการคำนวณแบบกำหนดค่าที่อนุญาตให้มีการโต้ตอบระดับกลางกับโลก

สำหรับคำอธิบายเพิ่มเติมดูคำตอบนี้

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

ตามที่ฉันเข้าใจแล้วมีคนชื่อEugenio Moggiแรกสังเกตว่าการสร้างทางคณิตศาสตร์ที่คลุมเครือก่อนหน้านี้เรียกว่า "monad" สามารถใช้เพื่อจำลองผลข้างเคียงในภาษาคอมพิวเตอร์และด้วยเหตุนี้จึงระบุความหมายของพวกเขาโดยใช้ เมื่อ Haskell ได้รับการพัฒนามีหลายวิธีในการคำนวณแบบไม่บริสุทธิ์ (ดูรายละเอียดเพิ่มเติมจาก"ผมเสื้อเชิ้ต" ของ Simon Peyton Jones ) แต่เมื่อ Phil Wadler ได้แนะนำพระอย่างรวดเร็วกลายเป็นที่ชัดเจนว่านี่คือคำตอบ และที่เหลือคือประวัติศาสตร์

ใครบ้างให้คำแนะนำว่าทำไมการคำนวณแบบไม่บริสุทธิ์ใน Haskell ถูกจำลองเป็นพระ?

ดีเพราะ Haskell เป็นบริสุทธิ์ คุณจำเป็นต้องมีแนวคิดทางคณิตศาสตร์เพื่อแยกความแตกต่างระหว่างการคำนวณแบบไม่บริสุทธิ์และแนวคิดบริสุทธิ์ในระดับประเภทและกับการไหลของโปรแกรมแบบจำลองตามลำดับ

ซึ่งหมายความว่าคุณจะต้องจบด้วยประเภทIO aที่คำนวณแบบไม่บริสุทธิ์ จากนั้นคุณจำเป็นต้องรู้วิธีการรวมการคำนวณเหล่านี้ซึ่งใช้ในลำดับ ( >>=) และการเพิ่มค่า ( return) เป็นวิธีที่ชัดเจนที่สุดและพื้นฐาน

ด้วยสองสิ่งนี้คุณได้กำหนด monad ไว้แล้ว (โดยไม่ต้องคิดเลย);)

นอกจากนี้ monads ให้แนวคิดทั่วไปมากและมีประสิทธิภาพหลายชนิดเพื่อให้การควบคุมการไหลสามารถทั่วไปเพื่อความสะดวกในการทำงานเช่นเอกsequence, liftMหรือไวยากรณ์พิเศษทำให้ unpureness ไม่ได้เช่นกรณีพิเศษ

ดูmonads ในการเขียนโปรแกรมการทำงานและการพิมพ์ที่ไม่ซ้ำกัน (ทางเลือกเดียวที่ฉันรู้) สำหรับข้อมูลเพิ่มเติม

อย่างที่คุณพูดMonadมันเป็นโครงสร้างที่ง่ายมาก ครึ่งหนึ่งของคำตอบคือ: Monadโครงสร้างที่ง่ายที่สุดที่เราสามารถมอบให้กับฟังก์ชั่นปรับผลข้างเคียงและสามารถใช้งานได้ ด้วยการที่Monadเราสามารถทำสองสิ่ง: เราสามารถรักษาคุณค่าที่บริสุทธิ์เป็นค่าผลข้างเคียง ( return) และเราสามารถใช้ฟังก์ชั่นผลข้างเคียงกับค่าผลข้างเคียงเพื่อรับค่าผลข้างเคียงใหม่ ( >>=) การสูญเสียความสามารถในการทำสิ่งใดสิ่งหนึ่งเหล่านี้จะทำให้หมดอำนาจดังนั้นประเภทผลข้างเคียงของเราต้องเป็น "อย่างน้อย" Monadและปรากฎว่าMonadเพียงพอที่จะใช้ทุกอย่างที่เราต้องการจนถึงตอนนี้

อีกครึ่งหนึ่งคือโครงสร้างที่มีรายละเอียดมากที่สุดที่เราสามารถมอบให้กับ "ผลข้างเคียงที่เป็นไปได้" คืออะไร เราสามารถคิดถึงผลข้างเคียงที่เป็นไปได้ทั้งหมดอย่างแน่นอนในชุด (การดำเนินการเดียวที่ต้องมีคือการเป็นสมาชิก) เราสามารถรวมเอฟเฟกต์สองข้างด้วยการทำทีละอันและสิ่งนี้จะทำให้เกิดผลข้างเคียงที่แตกต่างกัน (หรืออาจเป็นอันเดียวกัน - ถ้าอันแรกคือ "คอมพิวเตอร์ปิดเครื่อง" และอันที่สองคือ "เขียนไฟล์" ดังนั้นผลลัพธ์ การเขียนสิ่งเหล่านี้เป็นเพียง "คอมพิวเตอร์ปิดเครื่อง")

ตกลงเราจะพูดอะไรเกี่ยวกับการดำเนินการนี้ มันเชื่อมโยง; นั่นคือถ้าเรารวมผลข้างเคียงสามอย่างเข้าด้วยกันมันไม่สำคัญว่าเราจะรวมอะไรเข้าด้วยกันถ้าเราทำ (เขียนไฟล์แล้วอ่านซ็อกเก็ต) จากนั้นปิดคอมพิวเตอร์แล้วมันก็เหมือนกับการเขียนไฟล์แล้ว (อ่านซ็อกเก็ตแล้วปิด คอมพิวเตอร์). แต่ไม่ใช่การสลับ: ("เขียนไฟล์" จากนั้น "ลบไฟล์") เป็นผลข้างเคียงที่แตกต่างจาก ("ลบไฟล์" จากนั้น "เขียนไฟล์") และเรามีอัตลักษณ์: ผลข้างเคียงพิเศษ "ไม่มีผลข้างเคียง" ทำงาน ("ไม่มีผลข้างเคียง" จากนั้น "ลบไฟล์" เป็นผลข้างเคียงเช่นเดียวกับ "ลบไฟล์") ณ จุดนี้นักคณิตศาสตร์ทุกคนกำลังคิดว่า "กลุ่ม!" แต่กลุ่มมีผู้รุกรานและไม่มีวิธีที่จะกลับผลข้างเคียงโดยทั่วไป "ลบไฟล์" กลับไม่ได้ ดังนั้นโครงสร้างที่เราทิ้งไว้คือโมโนoidซึ่งหมายความว่าฟังก์ชันที่มีผลข้างเคียงของเราควรเป็น monads

มีโครงสร้างที่ซับซ้อนกว่านี้ไหม? แน่นอน! เราสามารถแบ่งผลข้างเคียงที่เป็นไปได้ออกมาเป็นผลกระทบที่อิงกับระบบไฟล์เอฟเฟกต์บนเครือข่ายและอื่น ๆ อีกมากมายและเราสามารถสร้างกฎการแต่งเพลงที่ซับซ้อนยิ่งขึ้นซึ่งรักษารายละเอียดเหล่านี้ไว้ แต่มันกลับลงมาอีกครั้ง: Monadเรียบง่ายและมีประสิทธิภาพเพียงพอที่จะแสดงคุณสมบัติส่วนใหญ่ที่เราใส่ใจ (โดยเฉพาะอย่างยิ่งการเชื่อมโยงและสัจพจน์อื่น ๆ ให้เราทดสอบแอปพลิเคชันของเราเป็นชิ้นเล็ก ๆ ด้วยความมั่นใจว่าผลข้างเคียงของแอปพลิเคชันแบบรวมจะเหมือนกับการรวมกันของผลข้างเคียงของชิ้นส่วน)

จริงๆแล้วมันค่อนข้างเป็นวิธีที่สะอาดในการคิดถึง I / O ในลักษณะที่ใช้งานได้

ในภาษาการเขียนโปรแกรมส่วนใหญ่คุณทำการอินพุต / เอาต์พุต ใน Haskell ลองนึกภาพการเขียนรหัสไม่ต้องทำการดำเนินการ แต่เพื่อสร้างรายการการดำเนินการที่คุณต้องการทำ

Monads เป็นเพียงแค่รูปแบบที่สวยงาม

หากคุณต้องการทราบว่าทำไมพระสงฆ์ต่างจากสิ่งอื่นฉันเดาคำตอบว่ามันเป็นวิธีการทำงานที่ดีที่สุดในการเป็นตัวแทน I / O ที่ผู้คนสามารถนึกถึงเมื่อพวกเขากำลังสร้าง Haskell

AFAIK เหตุผลคือสามารถรวมการตรวจสอบผลข้างเคียงในระบบชนิด หากคุณต้องการทราบเพิ่มเติมให้ฟังตอนSE-Radioเหล่านั้น: ตอนที่ 108: Simon Peyton Jones เกี่ยวกับการเขียนโปรแกรมเชิงฟังก์ชั่นและ Haskell ตอนที่ 72: Erik Meijer บน LINQ

ข้างต้นมีคำตอบที่ดีมากกับพื้นหลังทางทฤษฎี แต่ฉันต้องการให้มุมมองของฉันใน IO monad ฉันไม่ได้มีประสบการณ์โปรแกรมเมอร์ Haskell ดังนั้นอาจเป็นว่าไร้เดียงสาหรือผิด แต่ฉันช่วยฉันจัดการกับ IO monad ในระดับหนึ่ง (โปรดทราบว่ามันไม่เกี่ยวข้องกับ monads อื่น ๆ )

ครั้งแรกที่ฉันต้องการพูดว่าตัวอย่างของ "โลกแห่งความจริง" นั้นไม่ชัดเจนสำหรับฉันเนื่องจากเราไม่สามารถเข้าถึงสถานะก่อนหน้า (โลกแห่งความจริง) ของมันได้ อาจไม่เกี่ยวข้องกับการคำนวณ monad เลย แต่เป็นที่ต้องการในแง่ของความโปร่งใสในการอ้างอิงซึ่งโดยทั่วไปแล้วจะแสดงในรหัส Haskell

ดังนั้นเราจึงต้องการให้ภาษาของเรา (ฮาเซล) บริสุทธิ์ แต่เราต้องการการใช้งานอินพุต / เอาท์พุตเนื่องจากไม่มีโปรแกรมของเราจะไม่มีประโยชน์ และการดำเนินการเหล่านั้นไม่สามารถบริสุทธิ์ได้โดยธรรมชาติ ดังนั้นวิธีเดียวที่จะจัดการกับเรื่องนี้เราต้องแยกการดำเนินการที่ไม่บริสุทธิ์ออกจากส่วนที่เหลือของรหัส

ที่นี่ monad มา ที่จริงแล้วฉันไม่แน่ใจว่าไม่มีสิ่งก่อสร้างอื่นที่มีคุณสมบัติที่ต้องการเหมือนกัน แต่ประเด็นคือ monad มีคุณสมบัติเหล่านี้ดังนั้นจึงสามารถใช้งานได้ (และใช้สำเร็จ) คุณสมบัติหลักคือเราไม่สามารถหนีจากมันได้ อินเทอร์เฟซ Monad ไม่มีการดำเนินการเพื่อกำจัด monad รอบค่าของเรา Monads (ไม่ใช่ IO) อื่น ๆ จัดเตรียมการดำเนินการดังกล่าวและอนุญาตการจับคู่รูปแบบ (เช่นอาจ) แต่การดำเนินการเหล่านั้นไม่ได้อยู่ในส่วนต่อประสาน Monad คุณสมบัติที่จำเป็นอีกประการหนึ่งคือความสามารถในการปฏิบัติการลูกโซ่

หากเราคิดเกี่ยวกับสิ่งที่เราต้องการในแง่ของระบบพิมพ์เรามาถึงความจริงที่ว่าเราต้องการพิมพ์ด้วยตัวสร้างซึ่งสามารถล้อมรอบหุบเขาใด ๆ ตัวสร้างจะต้องเป็นแบบส่วนตัวเนื่องจากเราห้ามการหลบหนี (เช่นการจับคู่รูปแบบ) แต่เราต้องการฟังก์ชั่นเพื่อให้คุณค่ากับคอนสตรัคเตอร์นี้ และเราต้องการวิธีการปฏิบัติการลูกโซ่ หากเราคิดเกี่ยวกับมันสักพักเราจะพบความจริงว่าการดำเนินการผูกมัดต้องมีชนิดเป็น >> = มี ดังนั้นเรามาถึงบางสิ่งที่คล้ายกับ Monad ฉันคิดว่าถ้าตอนนี้เราวิเคราะห์สถานการณ์ที่ขัดแย้งกันได้ด้วยโครงสร้างนี้เราจะมาถึงสัจพจน์ monad

โปรดสังเกตว่าการสร้างที่พัฒนาแล้วไม่มีอะไรที่เหมือนกันกับมลทิน มันมีเพียงคุณสมบัติที่เราต้องการที่จะสามารถจัดการกับการปฏิบัติการที่ไม่บริสุทธิ์เช่นการไม่หนีการผูกมัดและวิธีการเข้า

ขณะนี้ชุดการดำเนินการไม่บริสุทธิ์บางส่วนถูกกำหนดไว้ล่วงหน้าโดยภาษาภายใน monad IO ที่เลือกนี้ เราสามารถรวมการดำเนินการเหล่านั้นเพื่อสร้างการดำเนินการที่ไม่บริสุทธิ์ใหม่ และการดำเนินการทั้งหมดนั้นจะต้องมี IO ในประเภทของพวกเขา อย่างไรก็ตามโปรดทราบว่าการปรากฏตัวของ IO ในประเภทของฟังก์ชั่นบางอย่างไม่ได้ทำให้ฟังก์ชั่นนี้ไม่บริสุทธิ์ แต่อย่างที่ฉันเข้าใจมันเป็นความคิดที่ไม่ดีที่จะเขียนฟังก์ชั่นบริสุทธิ์ด้วย IO ในประเภทของพวกเขาในตอนแรกมันเป็นความคิดของเราที่จะแยกฟังก์ชั่นบริสุทธิ์และไม่บริสุทธิ์

ในที่สุดฉันอยากจะบอกว่า monad ไม่เปลี่ยนปฏิบัติการที่ไม่บริสุทธิ์ให้กลายเป็นสิ่งบริสุทธิ์ ช่วยให้แยกพวกเขาได้อย่างมีประสิทธิภาพเท่านั้น (ฉันพูดซ้ำมันเป็นเพียงความเข้าใจของฉัน)