Người đăng ký soạn, đơn không

Người đăng ký soạn, đơn nguyên thì không.

Câu nói trên có nghĩa là gì? Và khi nào thì cái này thích hơn cái khác?

Nếu chúng ta so sánh các loại

(<*>) :: Applicative a => a (s -> t) -> a s -> a t
(>>=) :: Monad m =>       m s -> (s -> m t) -> m t

chúng tôi nhận được manh mối về những gì phân tách hai khái niệm. Điều đó (s -> m t)trong loại (>>=)cho thấy rằng một giá trị trong scó thể xác định hành vi của một phép tính trong m t. Đơn nguyên cho phép giao thoa giữa các lớp giá trị và tính toán. Các (<*>)nhà điều hành cho phép không có sự can thiệp như: chức năng và lập luận tính toán không phụ thuộc vào giá trị. Điều này thực sự cắn. Đối chiếu

miffy :: Monad m => m Bool -> m x -> m x -> m x
miffy mb mt mf = do
  b <- mb
  if b then mt else mf

trong đó sử dụng kết quả của một số hiệu ứng để quyết định giữa hai phép tính (ví dụ: phóng tên lửa và ký hiệp định đình chiến), trong khi

iffy :: Applicative a => a Bool -> a x -> a x -> a x
iffy ab at af = pure cond <*> ab <*> at <*> af where
  cond b t f = if b then t else f

trong đó sử dụng giá trị của abđể lựa chọn giữa các giá trị của hai phép tính atvà af, đã thực hiện cả hai, có lẽ gây ra hậu quả bi thảm.

Phiên bản đơn nguyên về cơ bản dựa vào sức mạnh bổ sung của (>>=)việc chọn phép tính từ một giá trị và điều đó có thể quan trọng. Tuy nhiên, việc hỗ trợ sức mạnh đó khiến các monads khó có thể soạn thảo. Nếu chúng tôi cố gắng xây dựng 'liên kết kép'

(>>>>==) :: (Monad m, Monad n) => m (n s) -> (s -> m (n t)) -> m (n t)
mns >>>>== f = mns >>-{-m-} \ ns -> let nmnt = ns >>= (return . f) in ???

chúng ta đi được xa đến mức này, nhưng bây giờ các lớp của chúng ta đều bị lộn xộn. Chúng ta có một n (m (n t)), vì vậy chúng ta cần phải loại bỏ cái bên ngoài n. Như Alexandre C nói, chúng ta có thể làm điều đó nếu chúng ta có

swap :: n (m t) -> m (n t)

để hoán vị phần ntrong và phần bên trong joinvới phần kia n.

'Áp dụng kép' yếu hơn dễ xác định hơn nhiều

(<<**>>) :: (Applicative a, Applicative b) => a (b (s -> t)) -> a (b s) -> a (b t)
abf <<**>> abs = pure (<*>) <*> abf <*> abs

vì không có sự giao thoa giữa các lớp.

Tương ứng, thật tốt để nhận ra khi nào bạn thực sự cần thêm sức mạnh của Monads và khi nào bạn có thể thoát khỏi cấu trúc tính toán cứng nhắc Applicativehỗ trợ.

Nhân tiện, xin lưu ý rằng mặc dù việc soạn thảo các monads rất khó, nhưng nó có thể nhiều hơn mức bạn cần. Kiểu m (n v)chỉ ra tính toán với m-effects, sau đó tính toán với n-effects thành -value v, trong đó m-effects kết thúc trước khi n-effects bắt đầu (do đó cần swap). Nếu bạn chỉ muốn xen kẽ m-effects với n-effects, thì bố cục có lẽ là quá nhiều để yêu cầu!

Người đăng ký soạn, đơn nguyên thì không.

Đơn nguyên có thể soạn, nhưng kết quả có thể không phải là đơn nguyên. Ngược lại, thành phần của hai ứng dụng nhất thiết phải là một ứng dụng. Tôi nghi ngờ ý định của tuyên bố ban đầu là "Tính ứng dụng là sáng tác, trong khi tính đơn nguyên thì không." Được diễn đạt lại, " Applicativeđược đóng theo thành phần, và Monadkhông."

Nếu bạn có các ứng dụng A1và A2thì kiểu đó data A3 a = A3 (A1 (A2 a))cũng là ứng dụng (bạn có thể viết một ví dụ như vậy theo cách chung chung).

Mặt khác, nếu bạn có đơn nguyên M1và M2thì kiểu đó data M3 a = M3 (M1 (M2 a))không nhất thiết phải là đơn nguyên (không có cách triển khai chung hợp lý cho >>=hoặc joincho bố cục).

Một ví dụ có thể là kiểu [Int -> a](ở đây chúng ta soạn một hàm tạo kiểu []với (->) Int, cả hai đều là đơn nguyên). Bạn có thể dễ dàng viết

app :: [Int -> (a -> b)] -> [Int -> a] -> [Int -> b]
app f x = (<*>) <$> f <*> x

Và điều đó khái quát cho bất kỳ ứng dụng nào:

app :: (Applicative f, Applicative f1) => f (f1 (a -> b)) -> f (f1 a) -> f (f1 b)

Nhưng không có định nghĩa hợp lý về

join :: [Int -> [Int -> a]] -> [Int -> a]

Nếu bạn không tin vào điều này, hãy xem xét biểu thức này:

join [\x -> replicate x (const ())]

Độ dài của danh sách trả về phải được đặt bằng đá trước khi cung cấp một số nguyên, nhưng độ dài chính xác của nó phụ thuộc vào số nguyên được cung cấp. Do đó, không có joinchức năng chính xác nào có thể tồn tại cho loại này.

Thật không may, mục tiêu thực sự của chúng tôi, thành phần của các monads, khá khó khăn hơn. .. Trong thực tế, chúng ta có thể thực sự chứng minh rằng, ở một khía cạnh nào đó, không có cách nào để xây dựng một hàm nối với kiểu trên mà chỉ sử dụng các phép toán của hai đơn thức (xem phần phụ lục để có dàn ý chứng minh). Theo đó, cách duy nhất mà chúng ta có thể hy vọng để tạo thành một bố cục là nếu có một số cấu trúc bổ sung liên kết hai thành phần.

Soạn monads, http://web.cecs.pdx.edu/~mpj/pubs/RR-1004.pdf

Giải luật phân phối l: MN -> NM là đủ

để đảm bảo tính đơn nguyên của NM. Để thấy điều này, bạn cần một đơn vị và một mult. tôi sẽ tập trung vào mult (đơn vị là unit_N unitM)

NMNM - l -> NNMM - mult_N mult_M -> NM

Điều này không đảm bảo rằng MN là một đơn nguyên.

Tuy nhiên, quan sát quan trọng sẽ phát huy tác dụng khi bạn có các giải pháp luật phân phối

l1 : ML -> LM
l2 : NL -> LN
l3 : NM -> MN

do đó, LM, LN và MN là các đơn nguyên. Câu hỏi đặt ra là liệu LMN có phải là một đơn nguyên hay không (bởi

(MN) L -> L (MN) hoặc bằng N (LM) -> (LM) N

Chúng tôi có đủ cấu trúc để tạo ra những bản đồ này. Tuy nhiên, như Eugenia Cheng quan sát , chúng ta cần một điều kiện lục giác (tương đương với việc trình bày phương trình Yang-Baxter) để đảm bảo tính đơn nguyên của một trong hai công trình. Thực ra, với điều kiện lục thức, hai đơn nguyên khác nhau lại trùng khớp.