在>>=和>>运营商都infixl 1.为什么左关联?
特别是,我观察到等价:
(do a; b; c ) == (a >> (b >> c)) -- Do desugaring
(a >> b >> c) == ((a >> b) >> c) -- Fixity definition
Run Code Online (Sandbox Code Playgroud)
因此do,对于固定性定义自然如何工作的方式不同,这是令人惊讶的.
lef*_*out 14
>>= 肯定是左联想的.
Prelude> ["bla","bli di","blub"] >>= words >>= reverse
"albilbidbulb"
Prelude> ["bla","bli di","blub"] >>= (words >>= reverse)
<interactive>:3:30: error:
• Couldn't match expected type ‘[[b0]]’
with actual type ‘String -> [String]’
• Probable cause: ‘words’ is applied to too few arguments
In the first argument of ‘(>>=)’, namely ‘words’
In the second argument of ‘(>>=)’, namely ‘(words >>= reverse)’
In the expression:
["bla", "bli di", "blub"] >>= (words >>= reverse)
Run Code Online (Sandbox Code Playgroud)
并且>>几乎遵循>>=; 如果它有另一个固定性,它不仅 会像Lennart所说的那样感到怪异,它还会阻止你在链中使用这两个运算符:
Prelude> ["bla","bli di","blub"] >>= words >> "Ha"
"HaHaHaHa"
Prelude> infixr 1 ??; (??) = (>>)
Prelude> ["bla","bli di","blub"] >>= words ?? "Ha"
<interactive>:6:1: error:
Precedence parsing error
cannot mix ‘>>=’ [infixl 1] and ‘??’ [infixr 1] in the same infix expression
Run Code Online (Sandbox Code Playgroud)
>>=是左关联的,因为它很方便.正如评论中所指出的m >>= f1 >>= f2那样(m >>= f1) >>= f2,我们希望将其解析为m >>= (f1 >>= f2)可能不会进行类型检查的情况.
>>然而,相关性只是一面镜子>>=.这可能是为了保持一致,因为我们可以>>通过第三个monad定律证明它是联想的:(m >>= f) >>= g ? m >>= ( \x -> f x >>= g ).也就是说,它的相关性在理论上并不重要.这是证明:
-- Definition:
a >> b ? a >>= (\_ -> b)
-- Proof: (a >> b) >> c ? a >> (b >> c)
(a >> b) >> c
? (a >>= (\_ -> b)) >> c -- [Definition]
? (a >>= (\_ -> b)) >>= (\_ -> c) -- [Definition]
? a >>= (\x -> (\_ -> b) x >>= (\_ -> c)) -- [Monad law]
? a >>= (\_ -> b >>= (\_ -> c)) -- [Beta-reduction]
? a >>= (\_ -> b >> c) -- [Definition]
? a >> (b >> c) -- [Definition]
?
Run Code Online (Sandbox Code Playgroud)
do - 注释因糖具有不同的目标而不同.从本质上讲,由于do-notation本质上是写出lambda,因此需要正确的关联.这是因为m >>= (\v -> (...))写成do {v <- m; (...)}.如前所述,为了保持一致性,>>这里的脱糖似乎>>=也是如此.