第 15 章：使用 Monad 编程
=========================

.. _golfing-practice-association-lists:

高尔夫训练：关联列表
--------------------

Web客户端和服务器通常通过简单的文本键值对列表来传输消息，例如：

::

	name=Attila+%42The+Hun%42&occupation=Khan
	
这种编码方式被称作 ``application/x-www-form-urlencoded``，这种方式非常容易理解：每个键值对通过 ``&`` 划分。在一个键值对中，键由一系列 URL 编码字符构成，键后紧跟着 ``=`` 和值（如果存在的话）。

很明显我们可以用一个 ``String`` 来表示键，但 HTTP 没有明确指出一个键是否必须有对应的值。我们可以将值用 ``Maybe String`` 表示以捕获歧义，当我们使用 ``Nothing`` 时，值不存在，当我们用 ``Just`` 包装一个 ``String`` 时，值存在。使用 ``Maybe`` 允许我们区分“值不存在”和“空值”。[译注： ``application/x-www-form-urlencoded`` 实际是在 HTML 的 Forms 部分定义的，而非原著中的 HTML]

Haskell程序员使用 :ref:`association-lists` 表示类型 ``[(a, b)]``，你可以把列表中的每个元素理解为一个键和值的关联。关联列表的名称起源于 Lisp 社区，通常缩写为列表，因此我们可以将上述字符串表示为以下的 Haskell 值。

::

	-- file: ch15/MovieReview.hs
	[("name",       Just "Attila \"The Hun\""),
	 ("occupation", Just "Khan")]

在 :ref:`parsing-an-url-encoded-query-string` 中，我们将解析一个 ``application/x-www-form-urlencoded`` 编码的字符串，并使用形如 ``[(String, Maybe String)]`` 的关联列表表示结果。假设我们想使用这些列表中的一个来填充一个数据结构。

::

	-- file: ch15/MovieReview.hs
	data MovieReview = MovieReview {
		  revTitle :: String
	    , revUser :: String
        , revReview :: String
		}
		
我们首先用一个简单的函数说明：

::

	-- file: ch15/MovieReview.hs
	simpleReview :: [(String, Maybe String)] -> Maybe MovieReview
	simpleReview alist =
	  case lookup "title" alist of
		Just (Just title@(_:_)) ->
		  case lookup "user" alist of
			Just (Just user@(_:_)) ->
			  case lookup "review" alist of
				Just (Just review@(_:_)) ->
					Just (MovieReview title user review)
				_ -> Nothing -- no review
			_ -> Nothing -- no user
		_ -> Nothing -- no title


当且仅当作为参数的关联列表包含了所有必须的键值对，并且这些键值对中的值不为空时，函数 ``simpleReview`` 将返回一个 ``MovieReview`` 。然而，它的优点仅仅是能够验证输入是否合法，实际上它采用了应当尽量避免的“锯齿型（staircasing）”代码结构，并且它过于了解关联列表的表示细节。

我们已经对 ``Maybe`` monad 非常熟悉了，上面的代码可以整理一下，让它避免“锯齿化”结构。

::

	-- file: ch15/MovieReview.hs
	maybeReview alist = do
		title <- lookup1 "title" alist
		user <- lookup1 "user" alist
		review <- lookup1 "review" alist
		return (MovieReview title user review)

	lookup1 key alist = case lookup key alist of
						  Just (Just s@(_:_)) -> Just s
						  _ -> Nothing


代码看起来整洁了许多，但其中仍存在重复的工作。我们可以利用 ``MovieReview`` 构造器是普通纯函数的性质，将其提升为 monad，就像我们在 :ref:`mixing-pure-and-monadic-code` 讨论过的那样。

::

	-- file: ch15/MovieReview.hs
	liftedReview alist =
		liftM3 MovieReview (lookup1 "title" alist)
						   (lookup1 "user" alist)
						   (lookup1 "review" alist)

在上面这段代码中依旧存在很多重复的工作，但它们已经显著减少了，并且我们很难去除剩下的部分。

.. _generalised-lifting:

广义的提升
----------

虽然使用 ``liftM3`` 让我们的代码更加整洁，但我们不能用一堆 ``liftM`` 去解决更广泛的问题，因为标准库只定义到了 ``liftM5``。事实上我们可以根据我们的需要写出任意数字的 ``liftM`` ，但那将是非常繁重的工作。

假设我们有一个构造器或者纯函数，并且接受 10 个参数，这时候再坚持用标准库，你恐怕就觉得我们没有那么好运了。

当然，标准库里面还有其他工具可用，在 ``Control.Monad`` 中，有一个函数 ``ap``，它的类型签名（type signature）非常有趣。

::

	ghci> :m +Control.Monad
	ghci> :type ap
	ap :: (Monad m) => m (a -> b) -> m a -> m b

你可能会觉得奇怪，谁会把一个接受单一参数的纯函数放到 monad 中，这么做的原因又是什么？回想一下，其实所有的 Haskell 函数本质上都是接受单一参数，``MovieReview`` 的构造器也是这样。

::

	ghci> :type MovieReview
	MovieReview :: String -> String -> String -> MovieReview
	
我们可以将类型签名写成 ``String -> (String -> String -> MovieReview)``。假如我们使用 ``liftM`` 将 ``MovieReview`` 提升为 ``Maybe`` monad，我们将得到一个类型为 ``Maybe (String -> (String -> (String -> MovieReview)))``的值。这个类型恰好是 ``ap`` 接受的参数的类型，并且 ``ap`` 的返回类型将是 ``Maybe (String -> (String -> MovieReview))``。我们可以将 ``ap`` 返回的值继续传入 ``ap`` ，直到我们结束这个定义。

::

	-- file: ch15/MovieReview.hs
	apReview alist =
		MovieReview `liftM` lookup1 "title" alist
					   `ap` lookup1 "user" alist
					   `ap` lookup1 "review" alist

.. warning::

    [译注：原著这里存在错误，上面的译文直接翻译了原著，在此做出修正。使用 ``liftM`` 将 ``MovieReview`` 提升为 ``Maybe`` monad后，得到的类型不是 ``Maybe (String -> (String -> (String -> MovieReview)))``，而是 ``Maybe String -> Maybe (String -> (String -> MovieReview))``。下面给出在不断应用 ``ap`` 时，类型系统的显示变化过程。]

    ::
	
        -- note by translator
		MovieReview :: String -> ( String -> String -> MovieRevie )
		MovieReview `liftM` :: Maybe String -> Maybe ( String -> String -> MovieRevie )
		MovieReview `liftM` lookup1 "title" alist :: Maybe ( String -> String -> MovieRevie )
		MovieReview `liftM` lookup1 "title" alist `ap` :: Myabe String -> Maybe ( String -> MovieRevie )
		MovieReview `liftM` lookup1 "title" alist `ap` lookup1 "user" alist :: Maybe ( String -> MovieRevie )


我们可以通过不断应用 ``ap`` 来替代 ``liftM`` 的一系列函数。

这样理解 ``ap`` 可能会对你有所帮助：``ap`` 的 monadic 等价于我们熟悉的 ``($)`` 运算符，你可以想象一下把 ``ap`` 读成 ``apply``。通过观察这二者的类型签名，我们可以清晰地看到这一点。

::

	ghci> :type ($)
	($) :: (a -> b) -> a -> b
	ghci> :type ap
	ap :: (Monad m) => m (a -> b) -> m a -> m b

事实上，``ap`` 通常被定义为 ``liftM2 id`` 或者 ``liftM2 ($)``。[译注：如果你使用 ``:t`` 来观察这两种书写形式得到的类型签名，你会发现它们在类型细节上有所差异，这是由 ``id`` 和 ``($)`` 本身类型签名的不同导致的，``id``的签名是``a -> a``，而 ``($)`` 是 ``(a -> b) -> (a -> b)``，当然这对于广义的类型是等同的。]

.. _looking-for-alternatives:

寻找替代方案
------------

下面是通讯录中一项的简单表示。

::

	-- file: ch15/VCard.hs
	data Context = Home | Mobile | Business
				   deriving (Eq, Show)

	type Phone = String

	albulena = [(Home, "+355-652-55512")]

	nils = [(Mobile, "+47-922-55-512"), (Business, "+47-922-12-121"),
			(Home, "+47-925-55-121"), (Business, "+47-922-25-551")]

	twalumba = [(Business, "+260-02-55-5121")]
	
假设我们想给某个人打一个私人电话，我们必然会选择他的家庭号码（假如他有的话），而不是他的工作号码。

::

	-- file: ch15/VCard.hs
	onePersonalPhone :: [(Context, Phone)] -> Maybe Phone
	onePersonalPhone ps = case lookup Home ps of
							Nothing -> lookup Mobile ps
							Just n -> Just n
							
在上面的代码中，我们使用 ``Maybe`` 作为生成结果的类型，这样无法处理某个人有多个符合要求的号码的情况。因此，我们将返回类型转换为一个列表。

::
	
	-- file: ch15/VCard.hs
	allBusinessPhones :: [(Context, Phone)] -> [Phone]
	allBusinessPhones ps = map snd numbers
		where numbers = case filter (contextIs Business) ps of
						  [] -> filter (contextIs Mobile) ps
						  ns -> ns

	contextIs a (b, _) = a == b
	
注意，这两个函数中 ``case`` 表达式的结构非常相似：其中一个标签处理查找结果为空的情况，剩下的处理结果非空的情况。

::

	ghci> onePersonalPhone twalumba
	Nothing
	ghci> onePersonalPhone albulena
	Just "+355-652-55512"
	ghci> allBusinessPhones nils
	["+47-922-12-121","+47-922-25-551"]

[译注：这里的代码通过需要 ``:l`` 导入 ``VCard.hs`` ]

Haskell 的 ``Control.Monad`` 模块定义了一种类型类 ``MonadPlus`` ，这使我们可以将 ``case`` 表达式中的普通模式抽象出来。

::

	-- file: ch15/VCard.hs
	class Monad m => MonadPlus m where
	   mzero :: m a	
	   mplus :: m a -> m a -> m a
	   
值 ``mzero`` 表示了一个空结果， ``mplus`` 将两个结果合并为一个。下面是 ``mzero`` 和 ``mplus`` 针对 ``Maybe`` 和列表的标准定义。[译注：在约翰·休斯 1998 年发表的《Generalising Monads to Arrows》中，他提出 ``mzero`` 可理解为对失败情况的一种概括，而 ``mplus`` 则是对选择情况的概括，例如如果第一种情况失败，则尝试第二种。]

::
	
	-- file: ch15/VCard.hs
	instance MonadPlus [] where
	   mzero = []
	   mplus = (++)

	instance MonadPlus Maybe where
	   mzero = Nothing

	   Nothing `mplus` ys  = ys
	   xs      `mplus` _ = xs
	   
我们现在可以使用 ``mplus`` 替换掉整个 ``case`` 表达式。为了照顾情况的多样性，我们下面来获取通讯录中某人的一个工作号码和他所有的私人号码。

::

	-- file: ch15/VCard.hs
	oneBusinessPhone :: [(Context, Phone)] -> Maybe Phone
	oneBusinessPhone ps = lookup Business ps `mplus` lookup Mobile ps

	allPersonalPhones :: [(Context, Phone)] -> [Phone]
	allPersonalPhones ps = map snd $ filter (contextIs Home) ps `mplus`
									 filter (contextIs Mobile) ps
									 
[译注：在前面的例子中，我们将 ``mplus`` 作为 ``case`` 模式的一种抽象表达来介绍，但是对于 ``list`` monad，它会产生和前面例子不同的结果。考虑前面的例子 ``allBusinessPhones``，我们试图获取一个人的全部工作号码，当且仅当他没有工作号码时，结果中才包含私人号码。而 ``mplus`` 只是将全部工作号码和私人号码连接在一起，这和我们想要的结果有出入。]

我们已经知道 ``lookup`` 会返回一个 ``Maybe`` 类型的值，而 ``filter`` 将返回一个列表，所以对于这些函数，应当使用什么版本的 ``mplus`` 是非常显然的。

更有趣的是我们现在可以使用 ``mzero`` 和 ``mplus`` 来编写对任意 ``MonadPlus`` 实例均有效的函数。举例而言，下面是一个标准的 ``lookup`` 函数，它将返回一个 ``Maybe`` 类型的值。

::

	-- file: ch15/VCard.hs
	lookup :: (Eq a) => a -> [(a, b)] -> Maybe b
	lookup _ []                      = Nothing
	lookup k ((x,y):xys) | x == k    = Just y
						 | otherwise = lookup k xys
						 
通过下面的代码，我们可以很容易的将结果类型推广到 ``MonadPlus`` 的任意实例。

::

	-- file: ch15/VCard.hs
	lookupM :: (MonadPlus m, Eq a) => a -> [(a, b)] -> m b
	lookupM _ []    = mzero
	lookupM k ((x,y):xys)
		| x == k    = return y `mplus` lookupM k xys
		| otherwise = lookupM k xys
		
假如我们得到的结果是 ``Maybe`` 类型，那么通过这种方式我们将得到一个结果或“没有结果”；假如我们得到的结果是一个列表，那么我们将获得所有的结果；其它情况下，我们将获得一些适用于其它 ``MonadPlus`` 实例的结果。

对于一些类似我们上面展示的小函数，使用 ``mplus`` 没什么明显的优点。 ``mplus`` 的优点体现在更复杂的代码和那些独立于 monad 执行过程的代码中。即使你没有在自己的代码中碰到需要使用 ``MonadPlus`` 的情况，你也很可能在别人的项目中遇到它。

.. _the-name-mplus-does-not-imply-addition:

mplus 不意味着相加
^^^^^^^^^^^^^^^^^^

函数 ``mplus`` 的名字中包含了 “plus”，但这并不代表着我们一定是要将两个值相加。根据我们处理的 monad 的不同，有时 ``mplus`` 会实现看起来类似相加的操作。例如，列表 monad 中 ``mplus`` 等同于 ``(++)`` 运算符。

::

	ghci> [1,2,3] `mplus` [4,5,6]
	[1,2,3,4,5,6]
	
但是，假如我们切换到另一个 monad， ``mplus`` 和加法操作将不存在明显的相似性。

::

	ghci> Just 1 `mplus` Just 2
	Just 1

.. _rules-for-working-with-monadplus:

使用 MonadPlus 的规则
^^^^^^^^^^^^^^^^^^^^^

除了通常情况下 monad 的规则外， ``MonadPlus`` 类型类的实例必须遵循一些其他简单的规则。

如果一个捆绑表达式左侧出现了 ``mzero`` ，那么这个实例必须短路（short circuit）。换句话说，表达式 ``mzero >>= f`` 必须和单独的 ``mzero`` 效果相同。[译注：“短路” 也用来描述严格求值语言中布尔运算符的“短路”特性，例如 ``B != null && B.value != ""`` 可以避免在 ``B == null`` 时考量 ``B.value`` ]

::

	-- file: ch15/MonadPlus.hs
		mzero >>= f == mzero

如果 ``mzero`` 出现在了一个序列表达式的右侧，则这个实例必须短路。[译注：此处存在争议，例如 ``Maybe`` monad的一个例子 ``(undefined >> Nothing) = undefined /= Nothing`` 不满足这一条件。一种观点认为，短路特性意味着如果表达式中某个操作数的结果为某事，则不评估另一个操作数，也就是说必须首先评估一个操作数。所以，在“从左向右”和“从右向左”的短路之间，只能存在一种。]

::

	-- file: ch15/MonadPlus.hs
		v >> mzero == mzero

		
.. _failing-safely-with-monadplus:

通过 MonadPlus 安全地失败
^^^^^^^^^^^^^^^^^^^^^^^^^

当我们在 :ref:`the-monad-typeclass` 中介绍 ``fail`` 函数时，我们对它的使用提出了警告：在许多 monad 中，它可能被实现为一个对错误的调用，这会导致令人不愉快的后果。

``MonadPlus`` 类型类为我们提供了一种更温和的方法来使一个计算失败，这使我们不必面临使用 ``fail`` 和 ``error`` 带来的危险。上面介绍的规则允许我们在代码中需要的任何地方引入一个 ``mzero`` ，这样计算将在该处短路。

在 ``Control.Monad`` 模块中，标准函数 ``guard`` 将这个想法封装成了一种方便的形式。

::
	
	-- file: ch15/MonadPlus.hs
	guard        :: (MonadPlus m) => Bool -> m ()
	guard True   =  return ()
	guard False  =  mzero
	
作为一个简单的例子，这里有一个函数，它接受一个数 ``x`` 作为参数，并计算 ``x`` 对于另一个数 ``n`` 的取模结果。假如结果是 0 则返回 ``x`` ，否则返回当前 monad 对应的 ``mzero`` 。

::

	-- file: ch15/MonadPlus.hs
	x `zeroMod` n = guard ((x `mod` n) == 0) >> return x
	
.. _adventures-in-hiding-the-plumbing:

隐藏管道
--------

在 :ref:`using-the-state-monad-generating-random-values` 中，我们展示了使用 ``State`` monad 生成随机数的简单方法。

我们编写的代码的一个缺点是它泄露了细节：使用者知道代码运行在 ``State`` monad中。这意味着他们可以像我们这些作者一样检测并修改随机数生成器的状态。

人的本性决定了，一旦我们将工作内部细节暴露出来，就会有人试图对其做手脚。对于一个足够小的程序，这也许没什么问题，但在更大的软件项目中，如果库的某个使用者使用了其他使用者都没有预料到的方式修改库，这一举动可能导致的错误将非常严重。因为问题出现在库中，而我们通常不会怀疑库有问题，所以这些错误很难被发现，直到我们排除了所有其他可能。

更糟糕的是，一旦程序的实现细节暴露，一些人将绕过我们提供的 API 并直接采用内部实现方式。当我们需要修复某个错误或者增强某个功能时，我们等于为自己设置了一道屏障。我们要么修改内部、破坏依赖它们的代码，要么坚持现有的内部结构并寻找其他方式来做出需要的改变。

我们该如何修改随机数 monad 来隐藏我们使用了 ``State`` monad 的事实？我们需要使用某种方式来阻止用户调用 ``get`` 或 ``put`` 。要实现这一点并不难，并且在具体实现中我们将会介绍一些在日常 Haskell 编程中经常使用的技巧。

为了扩大应用的范围，我们不用随机数做例子，而是实现了一个可以提供任意类型不重复值的 monad，这个 monad 叫做 ``Supply`` 。我们将为执行函数 ``runSupply`` 提供一个值的列表，并确保列表中每个值是独一无二的。

::

	-- file: ch15/Supply.hs
	runSupply :: Supply s a -> [s] -> (a, [s])

这个 monad 并不关心这些值是什么，它们可能是随机数，或临时文件的名称，或者是 HTTP cookie的标识符。

在这个 monad 中，每当用户要求获取一个值时， ``next`` 就会从列表中取出下一个值并将其交给用户。每个值都被 ``Maybe`` 构造器包装以防止这个列表的长度不满足需求。

::

	-- file: ch15/Supply.hs
	next :: Supply s (Maybe s)
	
为了隐藏我们的管道，在模块声明中我们只导出了类型构造函数，执行函数和 ``next`` 动作。

::

	-- file: ch15/Supply.hs
	module Supply
		(
		  Supply
		, next
		, runSupply
		) where
		
因为导入库的模块不能看到 monad 的内部，所以它不能修改我们的库。

我们的管道非常简单：使用一个 ``newtype`` 声明来包装现有的 ``State`` monad。

::

	-- file: ch15/Supply.hs
	import Control.Monad.State

	newtype Supply s a = S (State [s] a)
	
参数 ``s`` 是我们提供的独特值的类型， ``a`` 是我们必须提供的常见类型参数，以使我们的类型成为 monad。[译注：这里类型 ``a`` 是自由的，即 ``a`` 可以是任何东西，以允许 monadic 函数返回任何可能需要的类型。例如 ``hGetLine :: Handle - > IO String`` 这样一个 monadic 函数，给定一个文件句柄，将从它读取一行并返回这一行的内容。这里，``String`` 是 IO Monad 要返回的类型 ``a`` ，程序员可以将 ``hGetLine`` 看作从句柄读取 String 的函数。]

我们通过在 ``Supply`` 类型上应用 ``newtype`` 以及定义模块头来阻止用户使用 ``State`` monad 的 ``get`` 和 ``set`` 动作。因为我们的模块并不导出 ``s`` 的构造器，所以用户没有程序化的方式来查看或访问包装在 ``State`` monad 中的内容。

现在我们有了一个类型 ``Supply`` ，接下来需要定义一个 ``Monad`` 类型类的实例。我们可以遵循通常的方式如 ``(>>=)`` 和 ``return``，但这将变成纯样板代码。我们现在所做的是通过 ``s`` 值构造器将 ``State`` monad 版本的 ``(>>=)`` 及 ``return`` 包装和展开。代码看起来应该是这个样子：

::

	-- file: ch15/AltSupply.hs
	unwrapS :: Supply s a -> State [s] a
	unwrapS (S s) = s

	instance Monad (Supply s) where
		s >>= m = S (unwrapS s >>= unwrapS . m)
		return = S . return
		
Haskell 程序员不喜欢样板，GHC 有一个可爱的语言拓展功能消除了这一工作。我们将以下指令添加到源文件顶部（模块头之前）来使用这一功能。

::

	-- file: ch15/Supply.hs
	{-# LANGUAGE GeneralizedNewtypeDeriving #-}
	
通常我们只能自动导出一些标准类型类的实例如 ``Show`` 和 ``Eq`` 。顾名思义， ``GeneralizedNewtypeDeriving`` 拓展了我们派生类型类实例的能力，并且它特定于 ``newtype`` 的声明。通过下面的方式，如果我们包装的类型是任意一个类型类的实例，这个拓展可以自动让我们的新类型成为该类型类的实例。

::

	-- file: ch15/Supply.hs
		deriving (Monad)
		
[译注：在 GHC 7.10 中， ``Monad` 是 ``Applicative`` 和 ``Functor`` 的子类，因此上面的 ``deriving`` 需要改为 ``deriving(Functor, Applicative, Monad)`` 。] 
	
这需要底层类型实现 ``(>>=)`` 和 ``return`` ，通过 ``s`` 值构造器添加必要的包装和展开方法，并使用这些函数的新版本为我们导出一个 ``Monad`` 实例。[译注：这里的底层类型指的是 ``State`` 。]

我们在这里获得到的远比这个例子来的多。我们可以使用 ``newtype`` 来包装任何底层类型；我们选择性地只暴露符合我们想法的类型类实例；而且我们几乎没有花费更多的工作来创建这些更恰当、专业的类型。

现在我们已经看到了 ``GeneralizedNewtypeDeriving`` 技术，剩下的工作就是提供 ``next`` 和 ``runSupply`` 的定义。

::

	-- file: ch15/Supply.hs
	next = S $ do st <- get
				  case st of
					[] -> return Nothing
					(x:xs) -> do put xs
								 return (Just x)

	runSupply (S m) xs = runState m xs
	
我们可以将模块导入 **ghci** ，并用几种简单的方式尝试：

::

	ghci> :load Supply
	[1 of 1] Compiling Supply           ( Supply.hs, interpreted )
	Ok, modules loaded: Supply.
	ghci> runSupply next [1,2,3]
	Loading package mtl-1.1.0.0 ... linking ... done.
	(Just 1,[2,3])
	ghci> runSupply (liftM2 (,) next next) [1,2,3]
	((Just 1,Just 2),[3])
	ghci> runSupply (liftM2 (,) next next) [1]
	((Just 1,Nothing),[])
	
我们也可以验证 ``State`` monad 是否以某种方式泄露。

::

	ghci> :browse Supply
	data Supply s a
	next :: Supply s (Maybe s)
	runSupply :: Supply s a -> [s] -> (a, [s])
	ghci> :info Supply
	data Supply s a 	-- Defined at Supply.hs:17:8-13
	instance Monad (Supply s) -- Defined at Supply.hs:17:8-13
	
.. _supplying-random-numbers:

提供随机数
^^^^^^^^^^

如果我们想使用 ``Supply`` monad 作为随机数的源，那么有一些小困难需要克服。理想情况下，我们希望能为它提供一个无限的随机数流。我们可以在 ``IO`` monad 中获得一个 ``StdGen`` ，但完成后必须 “放回” 一个不同的 ``StdGen`` 。假如我们不这么做，下一段代码得到的 ``StdGen`` 将获得与之前相同的状态。这意味着它将产生与此前相同的随机数，这样的结果可能是灾难性的。

目前为止我们所看到的 ``System.Random`` 模块很难满足这些要求。我们可以使用 ``getStdRandom`` ，它的类型确保了我们可以同时得到和放回一个 ``StdGen`` 。

我们可以使用 ``random`` 在获取一个随机数的同时得到一个新的 ``StdGen`` 。我们可以用 ``randoms`` 获取一个无限的随机数列表。但我们如何同时得到一个无限的随机数列表和一个新的 ``StdGen``？

答案在于 ``RandomGen`` 类型类的拆分函数。它接受一个随机数生成器，并将其转换为两个生成器。能够分裂这样的随机生成器是一件很不寻常的事，它在纯函数的设定中显然非常有用，但对于非纯函数语言基本不需要。[译注： ``stdSplit`` 的统计基础较差，如果随机数的质量很重要，应当尽量避免不必要的分割。]

通过使用 ``split`` 函数，我们可以用一个 ``StdGen`` 来生成一个无限长的随机数列表并将其交付 ``runSupply`` ，同时将另一个 ``StdGen`` 返还给 ``IO`` monad。

::

	-- file: ch15/RandomSupply.hs
	import Supply
	import System.Random hiding (next)

	randomsIO :: Random a => IO [a]
	randomsIO =
		getStdRandom $ \g ->
			let (a, b) = split g
			in (randoms a, b)

如果我们正确的书写了这个函数，我们的例子应该在每次调用时打印一个不同的随机数。

::
	
	ghci> :load RandomSupply
	[1 of 2] Compiling Supply           ( Supply.hs, interpreted )
	[2 of 2] Compiling RandomSupply     ( RandomSupply.hs, interpreted )
	Ok, modules loaded: RandomSupply, Supply.
	ghci> (fst . runSupply next) `fmap` randomsIO

	<interactive>:1:17:
		Ambiguous occurrence `next'
		It could refer to either `Supply.next', imported from Supply at RandomSupply.hs:4:0-12
												  (defined at Supply.hs:32:0)
							  or `System.Random.next', imported from System.Random
	ghci> (fst . runSupply next) `fmap` randomsIO

	<interactive>:1:17:
		Ambiguous occurrence `next'
		It could refer to either `Supply.next', imported from Supply at RandomSupply.hs:4:0-12
												  (defined at Supply.hs:32:0)
							  or `System.Random.next', imported from System.Random
	
.. warning::
	
	[译注：此处保留了原著中的错误，原著执行的代码中可能丢失了 ``hiding (next)`` ，因此产生歧义。下面给出正确情况下的某次执行结果。]
	
	::
	
		ghci> :load RandomSupply
		[1 of 2] Compiling Supply           ( Supply.hs, interpreted )
		[2 of 2] Compiling Main             ( RandomSupply.hs, interpreted )
		Ok, modules loaded: Supply, Main.
		ghci> (fst . runSupply next) `fmap` randomsIO
		Just (-54705384517081531)
		ghci> (fst . runSupply next) `fmap` randomsIO
		Just (-2652939136952789000)
		ghci> (fst . runSupply next) `fmap` randomsIO
		Just (-5089130856647223466)
		
回想一下，我们的 ``runSupply`` 函数同时返回执行 monadic 操作的结果和列表的剩余部分。因为我们传递了一个无限的随机数列表，所以这里用 ``fst`` 来组合，以保证当 **ghci** 尝试打印结果时不会被随机数淹没。
	
.. _another-round-of-golf:

另一轮高尔夫训练
^^^^^^^^^^^^^^^^

这种将函数应用在一对元素的其中一个元素上，并且与另一个未被修改的原始元素构成新对的模式在 Haskell 代码中已经非常普遍，它已经成为了一种标准代码。

在 ``Control.Arrow`` 模块中有两个函数 ``first`` 和 ``second`` ，它们执行这个操作。

::

	ghci> :m +Control.Arrow
	ghci> first (+3) (1,2)
	(4,2)
	ghci> second odd ('a',1)
	('a',True)
	
（事实上我们已经在 :ref:`json_typeclasses_without_overlapping_instances` 中遇到过 ``second`` 了。）我们可以使用 ``first`` 来产生我们自己 ``randomsIO`` 的定义，将其转化为单线形式。

::

	-- file: ch15/RandomGolf.hs
	import Control.Arrow (first)

	randomsIO_golfed :: Random a => IO [a]
	randomsIO_golfed = getStdRandom (first randoms . split)
	
.. _separating-interface-from-implementation:

将接口与实现分离
----------------

在前面的章节中，我们看到了如何向用户隐藏我们在内部使用 ``State`` monad 来保持 ``Supply`` monad状态的事实。

使代码更加模块化的另一个重要方式是将接口（代码可以做什么）从实现（代码具体如何做）中分离出来。

众所周知，标准的随机数生成器 ``System.Random`` 速度很慢。如果使用我们的 ``randomsIO`` 函数为它提供随机数，那么我们的 ``next`` 动作执行效果将不会很好。

一个简单有效的解决办法是为 ``Supply`` 提供一个更好的随机数源，但现在让我们把这个方法先放到一边，转而考虑一种在许多设定中都有效的替代方法。我们将使用一个类型类，对 monad 的行为和实现进行分离。

::

	-- file: ch15/SupplyClass.hs
	class (Monad m) => MonadSupply s m | m -> s where
		next :: m (Maybe s)
		
这个类型类定义了任何 ``Supply`` monad 都必须实现的接口。因为这个类型类使用了几个我们尚不熟悉的 Haskell 语言扩展，所以我们需要对这个类型类进行详细的分析，它涉及的各个扩展将在接下来的小节中介绍。

.. _multi-parameter-typeclasses:

多参数类型类
^^^^^^^^^^^^

我们应该如何读取类型类中的代码片段 ``MonadSupply s m`` ？如果我们添加括号，则等价表达式是 ``( MonadSupply s ) m`` ，它看起来更清晰一些。换句话说，给定一些 ``Monad`` 类型变量 ``m`` ，我们可以让它成为类型类 ``MonadSupply s`` 的一个实例。与常规类型类不同，这里的类型类有一个参数。 [译注： `此链接 <http://www.haskell.org/ghc/docs/7.6-latest/html/users_guide/type-class-extensions.html#functional-dependencies>`_ 可能会帮助你更好地理解功能依赖及多参数类型类。实际上，上面给出的例子中， ``s`` 和 ``m`` 仅仅是两个参数，它们的位置可以互换。原作者通过加括号的方式，将其理解为一个参数和另一个有参数的类型类，也许在数学上正确，但译者认为此处可能导致读者的困惑。]

这个语言扩展被称作 ``MultiParamTypeClasses`` ，因为它允许类型类有多个参数。参数 ``s`` 的作用与 ``Supply`` 类型的参数相同：它代表了 ``next`` 动作发出的值。

注意，我们不需要在 ``MonadSupply s`` 的定义中提到 ``(>>=)`` 或 ``return`` ，因为类型类的上下文（超类）要求 ``MonadSupply s`` 必须已经是一个 ``Monad`` 。

.. _functional-dependencies:

功能依赖
^^^^^^^^

现在让我们回头看之前被忽略的代码段， ``| m -> s`` 是一个功能依赖，通常被称作 ``fundep`` 。我们可以将竖线 ``|`` 读作 “这样”，将箭头 ``->`` 读作“唯一确定”。我们的功能依赖建立了 ``m`` 和 ``s`` 之间的关系。

功能依赖由 ``FunctionalDependencies`` 语言编译指令管理。

我们声明 ``m`` 和 ``s`` 之间关系的目的是帮助类型检查器。回想一下，Haskell类型检查器本质上是一个定理证明器，并且它在操作上是保守的：它坚持这个证明过程必须终止。一个非终止的证明结果将导致编译器放弃或陷入无限循环。

通过功能依赖，我们告诉类型检查器，一旦它看到一些 monad ``m`` 在 ``MonadSupply s`` 的上下文中被使用，那么类型 ``s`` 就是唯一可以接受的类型。假如我们省略功能依赖，类型检查器就会放弃并返回一个错误消息。

我们很难描述 ``m`` 和 ``s`` 之间的关系究竟是什么，所以让我们来看一个该类型类具体的实例。

::

	-- file: ch15/SupplyClass.hs
	import qualified Supply as S

	instance MonadSupply s (S.Supply s) where
		next = S.next
		
这里，类型变量 ``m`` 由类型 ``S.Supply s`` 替换。因为功能依赖的存在，类型检查器知道当它看到类型 ``S.Supply s`` 时， 这个类型可以被当作类型类 ``MonadSupply s`` 的实例来使用。

假如没有功能依赖，类型检查器不会发现 ``MonadSupply s`` 和 ``Supply s`` 二者类型参数之间的关系，因此它将终止编译并产生一个错误。它们的定义本身将会编译，而类型错误直到我们尝试使用它的时候才会产生。

下面我们用一个例子剥离最后一层抽象：考虑类型 ``S.Supply Int`` 。我们可以不使用功能依赖而将其声明为 ``MonadSupply s`` 的一个实例。但是假如我们试图使用这个实例编写代码，编译器将无法得知类型的 ``Int`` 参数需要和类型类 ``s`` 的参数相同，因此它将报告一个错误。

功能依赖可能难以理解，并且它们被证明在实践中通常很难使用。幸运的是，功能依赖一般在和我们例子类似的简单情况下使用，此时它们不会导致什么麻烦。

.. _rounding-out-our-module:

舍入模块
^^^^^^^^

假如我们将类型类和实例保存在名为 ``SupplyClass.hs`` 的源文件中，那么就需要在文件中添加一个类似这样的模块头：

::

	-- file: ch15/SupplyClass.hs
	{-# LANGUAGE FlexibleInstances, FunctionalDependencies,
				 MultiParamTypeClasses #-}

	module SupplyClass
		(
		  MonadSupply(..)
		, S.Supply
		, S.runSupply
		) where
		
这个 ``FlexibleInstances`` 扩展是必须的，否则编译器不会接受我们的实例声明。这个扩展放宽了在某些情况下书写实例的一般规则，但同时仍然让编译器的类型检查器保证它的推导会结束。我们这里需要 ``FlexibleInstances`` 的原因是我们使用了功能依赖，具体的细节超过了本书所讨论的范畴。

.. note:: 如何知道是否需要一个语言扩展
	
	假如 GHC 因为需要启用某些语言扩展而不能编译一段代码，它会提醒我们哪些扩展需要使用。比如，假如它认为我们的代码需要 flexible 的实例支持，它将提醒我们使用 ``-XFlexibleInstances`` 选项编译。 ``-x`` 选项和 ``LANGUAGE`` 伪指令具有相同的效果：它们都可以启用一个特定的扩展。
	
最后，请注意我们正在从此模块中重新导出 ``runSupply`` 和 ``Supply`` 的名称。从一个模块中导出名称是完全合法的，即使它在另一个模块中被定义。在我们的例子中，这意味着客户端代码只需要导入 ``SupplyClass`` 模块，而不需要导入 ``Supply`` 模块。这减少了用户需要记住的 “移动部件” 的数量。
	

.. _programming-to-a-monads-interface:

对 monad 接口编程
^^^^^^^^^^^^^^^^^

下面是一个简单的函数，它从我们的 ``Supply`` monad 中获取两个值，将它们格式化为字符串，并返回它们。

::

	-- file: ch15/Supply.hs
	showTwo :: (Show s) => Supply s String
	showTwo = do
	  a <- next
	  b <- next
	  return (show "a: " ++ show a ++ ", b: " ++ show b)
	  
这份代码通过它的结果类型绑定到我们的 ``Supply`` monad。通过修改函数类型，我们可以在维持函数主体不变的情况下，将此方法推广至所有实现了 ``MonadSupply`` 接口的 monad。

::

	-- file: ch15/SupplyClass.hs
	showTwo_class :: (Show s, Monad m, MonadSupply s m) => m String
	showTwo_class = do
	  a <- next
	  b <- next
	  return (show "a: " ++ show a ++ ", b: " ++ show b)

.. _the-reader-monad:

Reader monad
------------

``State`` monad 让我们通过代码传递了一些可变状态。有时，我们希望能够传递一些不可变的状态，比如程序的配置数据。在这种情况下我们仍可以使用 ``State`` monad ，但这种做法有时候可能会错误地修改了不可变的数据。

让我们暂时忘记 monad 。考虑一个能满足我们要求的函数，它应当具有什么行为？它应当接收一个类型为 ``e`` （根据环境而定）的值，该值携带了我们要传入的数据；它应当返回一个其它类型 ``a`` 的值作为结果。我们希望整个函数的类型签名为 ``e -> a`` 。

为了将这个类型转化为一个方便的 ``Monad`` 实例，我们用一个 ``newtype`` 包装它。

::

	-- file: ch15/SupplyInstance.hs
	newtype Reader e a = R { runReader :: e -> a }
	
很容易将它转化为 ``Monad`` 实例。

::

	-- file: ch15/SupplyInstance.hs
	instance Monad (Reader e) where
		return a = R $ \_ -> a
		m >>= k = R $ \r -> runReader (k (runReader m r)) r

.. warning::
	
	[译注：在 **GHC** 7.10 中，你需要同时定义 ``Functor`` 和 ``Applicative`` 的实例，其中一种实现如下。]
	
	::
		
		instance Functor (Reader e) where
		__fmap f m = R $ \r -> f (runReader m r)

		instance Applicative (Reader e) where
		__pure = R . const
		__f <*> x = R $ \r -> runReader f r (runReader x r)
		
我们可以将类型 ``e`` 表示的值理解为计算某个表达式所处的环境。因为 ``return`` 动作应当在任何情况下都具有相同的效果，所以这段代码不必考虑 ``return`` 所处的环境。

为了让环境 ———— 也即是代码中的变量 ``r`` ———— 能够在当前和接下来的计算中使用，我们使用了比较复杂的 ``(>>=)`` 定义。

在 monad 中执行的一段代码可以通过 ``ask`` 来获取环境中包含的值。

::

	-- file: ch15/SupplyInstance.hs
	ask :: Reader e e
	ask = R id

在给定的一连串动作中，每次调用 ``ask`` 都将返回相同的值，因为存储在环境中的值不会改变。我们可以在 **ghci** 中方便地测试代码。

::
	
	ghci> runReader (ask >>= \x -> return (x * 3)) 2
	Loading package old-locale-1.0.0.0 ... linking ... done.
	Loading package old-time-1.0.0.0 ... linking ... done.
	Loading package random-1.0.0.0 ... linking ... done.
	6

``Reader`` monad 包含在标准 ``mtl`` 库中，它通常与 GHC 捆绑在一起。你可以在 ``Control.Monad.Reader`` 模块中找到它。你可能不明白设计这个 monad 的动机是什么，实际上它通常在复杂的代码中更有用。我们时常需要访问程序深处的一段配置信息，若将这些信息作为正常参数传递，我们需要对代码做一次极为痛苦的重构。如果将这些信息隐藏在 monad 的管道中，那么不关心配置信息的中间函数就不需要看到它们。

使用 ``Reader`` monad 最明显的动机将在 :ref:`monad-transformers` 中介绍，我们将讨论如何把几个 monad 合并为一个新的 monad 。那时候，我们将学会如何利用 ``Reader`` monad 去更好地控制状态，以便我们的代码可以通过 ``State`` monad 修改一些值，而其他值则保持不变。
	
.. _a-return-to-automated-deriving:

返回自动导出
------------

既然我们了解了 ``Reader`` monad ，下面让我们用它来创建一个 ``MonadSupply`` 类型类的实例。为了保持例子的简洁性，这里我们将违反 ``MonadSupply`` 的精神：我们的 ``next`` 动作将始终返回相同的值。

将 ``Reader`` 类型变成一个 ``MonadSupply`` 类实例是一个糟糕的想法，因为任意 ``Reader`` 都可以表现为一个 ``MonadSupply`` 。所以这样的做法通常没有任何意义。

事实上，我们在 ``Reader`` 的基础上创建一个 ``newtype`` 。这个 ``newtype`` 隐藏了内部使用 ``Reader`` 的事实。我们必须让类型成为我们关心的类型类的一个实例。通过激活 ``GeneralizedNewtypeDeriving`` 扩展功能，GHC 会帮助我们完成大部分困难的工作。

::

	-- file: ch15/SupplyInstance.hs
	newtype MySupply e a = MySupply { runMySupply :: Reader e a }
		deriving (Monad)

	instance MonadSupply e (MySupply e) where
		next = MySupply $ do
				 v <- ask
				 return (Just v)

		-- more concise:
		-- next = MySupply (Just `liftM` ask)

注意，类型必须是 ``MonadSupply e`` 的实例，而不是 ``MonadSupply`` 。如果我们省略了类型变量，编译器将会报错。[译注：在类型声明中指定类型依赖的方式是在类名和实例名中使用相同的参数名。]

要尝试我们的 ``MySupply`` 类型，首先创建一个能处理任何 ``MonadSupply`` 实例的简单函数。

::

	-- file: ch15/SupplyInstance.hs
	xy :: (Num s, MonadSupply s m) => m s
	xy = do
	  Just x <- next
	  Just y <- next
	  return (x * y)
	  
正如我们期望的那样，如果我们将 ``Supply`` monad 和 ``randomsIO`` 函数与上面这个函数结合，那么每次都会得到一个不同的结果。

::

	ghci> (fst . runSupply xy) `fmap` randomsIO
	-15697064270863081825448476392841917578
	ghci> (fst . runSupply xy) `fmap` randomsIO
	17182983444616834494257398042360119726
	
因为 ``MySupply`` monad 由两层 ``newtype`` 包装，为了使其更易使用，我们可以为它编写一个自定义的执行函数：

::

	-- file: ch15/SupplyInstance.hs
	runMS :: MySupply i a -> i -> a
	runMS = runReader . runMySupply
	
当我们通过这个执行函数来应用 ``xy`` 动作时，每次都会得到相同的结果。虽然代码没有改动，但因为我们在不同 ``MonadSupply`` 的实现下执行，所以它的行为改变了。

::

	ghci> runMS xy 2
	4
	ghci> runMS xy 2
	4
	
就像我们的 ``MonadSupply`` 类型类和 ``Supply`` monad，几乎所有常见的 Haskell monad 都建立在接口与实现分离的情况下。举个例子，我们介绍过两个 “属于” ``State`` monad 的函数 ``get`` 和 ``put`` ，它们事实上是 ``MonadState`` 类型类的方法； ``State`` 类型只是这个类的一个实例。

类似的，标准的 ``Reader`` monad 是类型类 ``MonadReader`` 的实例，它指定了 ``ask`` 方法。

我们上面讨论的接口和实现分离不止对于架构清洁有帮助，它重要的实际应用在日后将更加清楚。当我们在 :ref:`monad-transformers` 中开始合并 monad 时，我们会通过使用 ``GeneralizedNewtypeDeriving`` 和类型类来节约大量的工作。
	  
.. _hiding-the-io-monad:

隐藏 IO monad
-------------

``IO`` monad 的 “祝福”和 “诅咒” 都来源于它的过分强大。假如我们相信小心地使用类型能帮助我们杜绝程序错误，那么 ``IO`` monad 将成为错误的一个重要来源。因为 ``IO`` monad 对我们做的事情不加以限制，这使我们容易遭受各种意外。

我们如何驯服它的力量？假如我们想保证一段代码可以读取和写入本地文件，但它不能访问网络。这时我们不能使用 ``IO`` monad，因为它不会限制我们。

.. _using-a-newtype:

使用 newtype
^^^^^^^^^^^^

让我们创建一个新模块，它提供了一组读取和写入文件的功能。

::

	-- file: ch15/HandleIO.hs
	{-# LANGUAGE GeneralizedNewtypeDeriving #-}

	module HandleIO
		(
		  HandleIO
		, Handle
		, IOMode(..)
		, runHandleIO
		, openFile
		, hClose
		, hPutStrLn
		) where
		
	import System.IO (Handle, IOMode(..))
	import qualified System.IO

我们要创建有限制 ``IO`` 的第一步是使用 ``newtype`` 对其进行包装。

::

	-- file: ch15/HandleIO.hs
	newtype HandleIO a = HandleIO { runHandleIO :: IO a }
		deriving (Monad)
		
我们使用已经熟悉的技巧，从模块中导出类型构造函数和 ``runHandleIO`` 执行函数，但不导出数据构造器。这可以阻止在 ``HandleIO`` monad 中执行的代码获取它所包装的 ``IO`` monad。

剩下的工作就是包装我们希望 monad 允许的每个动作。这可以通过用 ``HandleIO`` 数据构造函数包装每个 ``IO`` 实现。

::

	-- file: ch15/HandleIO.hs
	openFile :: FilePath -> IOMode -> HandleIO Handle
	openFile path mode = HandleIO (System.IO.openFile path mode)

	hClose :: Handle -> HandleIO ()
	hClose = HandleIO . System.IO.hClose

	hPutStrLn :: Handle -> String -> HandleIO ()
	hPutStrLn h s = HandleIO (System.IO.hPutStrLn h s)
	
我们现在可以使用有限制的 ``HandleIO`` monad 来执行 I/O 操作。

::
	
	-- file: ch15/HandleIO.hs
	safeHello :: FilePath -> HandleIO ()
	safeHello path = do
	  h <- openFile path WriteMode
	  hPutStrLn h "hello world"
	  hClose h
	  
要执行这个动作，我们使用 ``runHandleIO`` 。

::

	ghci> :load HandleIO
	[1 of 1] Compiling HandleIO         ( HandleIO.hs, interpreted )
	Ok, modules loaded: HandleIO.
	ghci> runHandleIO (safeHello "hello_world_101.txt")
	Loading package old-locale-1.0.0.0 ... linking ... done.
	Loading package old-time-1.0.0.0 ... linking ... done.
	Loading package filepath-1.1.0.0 ... linking ... done.
	Loading package directory-1.0.0.0 ... linking ... done.
	Loading package mtl-1.1.0.0 ... linking ... done.
	ghci> :m +System.Directory
	ghci> removeFile "hello_world_101.txt"
	
假如我们试图用一种不被允许的方式排列一个在 ``HandleIO`` monad 中执行的动作，类型系统会加以阻止。

::
	
	ghci> runHandleIO (safeHello "goodbye" >> removeFile "goodbye")

	<interactive>:1:36:
		Couldn't match expected type `HandleIO a'
			   against inferred type `IO ()'
		In the second argument of `(>>)', namely `removeFile "goodbye"'
		In the first argument of `runHandleIO', namely
			`(safeHello "goodbye" >> removeFile "goodbye")'
		In the expression:
			runHandleIO (safeHello "goodbye" >> removeFile "goodbye")
	
.. _designing-for-unexpected-uses:

针对意外使用情况设计
^^^^^^^^^^^^^^^^^^^^

``HandleIO`` monad 有一个重要的小问题：我们可能偶尔需要一个 “逃生舱门” ，而 ``HandleIO`` monad 没有考虑到这种可能性。如果定义一个这样的 monad，我们很有可能会偶尔执行 monad 设计所不允许的 I/O 动作。

设计这个 monad 的目的是让我们更容易在普通情况下编写无错代码，而不是为了杜绝特殊情况发生。让我们给自己留一条出路。

``Conotrol.Monad.Trans`` 模块定义了一个 “标准逃生舱门” ： ``MonadIO`` 类型类。函数 ``liftIO`` 可以将一个 ``IO`` 动作嵌入另一个 monad 中。

::

	ghci> :m +Control.Monad.Trans
	ghci> :info MonadIO
	class (Monad m) => MonadIO m where liftIO :: IO a -> m a
		-- Defined in Control.Monad.Trans
	instance MonadIO IO -- Defined in Control.Monad.Trans
	
要实现这个类型类非常简单，只需要用我们自己的数据构造器将 ``IO`` 包装起来就可以了：

::

	-- file: ch15/HandleIO.hs
	import Control.Monad.Trans (MonadIO(..))

	instance MonadIO HandleIO where
		liftIO = HandleIO

通过审慎地使用 ``liftIO`` ，我们可以逃脱束缚，并在必要的时候调用 IO 操作。

::

	-- file: ch15/HandleIO.hs
	tidyHello :: FilePath -> HandleIO ()
	tidyHello path = do
	  safeHello path
	  liftIO (removeFile path)
	  
.. info:

	自动推导和 ``MonadIO``
	
	通过将类型类添加到 ``HandleIO`` 的 ``deriving`` 子式，我们可以让编译器自动导出一个 ``MonadIO`` 实例。事实上，这在生产代码中是一个常见的策略。为了将之前材料和 ``MonadIO`` 二者的表示分离，这里简单地避免了这样的方式。

.. _using-typeclasses:

使用类型类
^^^^^^^^^^

将 ``IO`` 隐藏到另一个 monad 的缺陷是我们仍然绑定到了一个具体的实现。假如要将 ``HandleIO`` 和一些其它的 monad 交换，就必须改变每个使用 ``HandleIO`` 的动作的类型。

一种替代方式是创建一个类型类。我们想从一个操作文件的 monad 中获取接口，这个类型类指定了这个接口。

::

	-- file: ch15/MonadHandle.hs
	{-# LANGUAGE FunctionalDependencies, MultiParamTypeClasses #-}

	module MonadHandle (MonadHandle(..)) where

	import System.IO (IOMode(..))

	class Monad m => MonadHandle h m | m -> h where
		openFile :: FilePath -> IOMode -> m h
		hPutStr :: h -> String -> m ()
		hClose :: h -> m ()
		hGetContents :: h -> m String

		hPutStrLn :: h -> String -> m ()
		hPutStrLn h s = hPutStr h s >> hPutStr h "\n"

现在，我们决定抽象出 monad 的类型和文件句柄的类型。为了满足类型检查器，这里添加了一个函数依赖：对于 ``MonadHandle`` 的任何实例，只有一个句柄类型可以使用。当 ``IO`` monad 成为这个类的一个实例时，我们使用一个普通的 ``Handle`` 。

::

	-- file: ch15/MonadHandleIO.hs
	{-# LANGUAGE FunctionalDependencies, MultiParamTypeClasses #-}

	import MonadHandle
	import qualified System.IO

	import System.IO (IOMode(..))
	import Control.Monad.Trans (MonadIO(..), MonadTrans(..))
	import System.Directory (removeFile)

	import SafeHello

	instance MonadHandle System.IO.Handle IO where
		openFile = System.IO.openFile
		hPutStr = System.IO.hPutStr
		hClose = System.IO.hClose
		hGetContents = System.IO.hGetContents
		hPutStrLn = System.IO.hPutStrLn

因为任何 ``MonadHandle`` 也必须是一个 ``Monad`` ，所以我们可以使用普通的 ``do`` 标识符编写修改文件的代码，而不需要关心它最终在哪个 monad 中执行。

::

	-- file: ch15/SafeHello.hs
	safeHello :: MonadHandle h m => FilePath -> m ()
	safeHello path = do
	  h <- openFile path WriteMode
	  hPutStrLn h "hello world"
	  hClose h

我们已经让 ``IO`` 成为这个类型类的一个实例，现在可以在 **ghci** 中执行这个动作：

::

	ghci> safeHello "hello to my fans in domestic surveillance"
	Loading package old-locale-1.0.0.0 ... linking ... done.
	Loading package old-time-1.0.0.0 ... linking ... done.
	Loading package filepath-1.1.0.0 ... linking ... done.
	Loading package directory-1.0.0.0 ... linking ... done.
	Loading package mtl-1.1.0.0 ... linking ... done.
	ghci> removeFile "hello to my fans in domestic surveillance"
	
使用类型类的好处在于，我们可以不需要接触过多代码并互换一个底层的 monad ，因为大多数代码不知道或不关心具体底层 monad 的实现。例如，可以用一个 monad 来替换 ``IO`` ，它会在文件写入时压缩文件。

通过类型类定义一个 monad 的接口有另一个好处：它允许其他人在 ``newtype`` 包装器中隐藏我们的实现，并自动派生他们想要暴露的类型类的实例。
	  
.. _isolation-and-testing:

隔离和测试
^^^^^^^^^^

事实上，因为 ``safeHello`` 函数没有使用 ``IO`` 类型，我们甚至可以使用不能执行 I/O 的 monad。通过这种方法，我们可以在纯粹且受控的环境中对那些在平常情况下会出现副作用的代码进行测试。

为此，我们将创建一个 monad，这个 monad 不会执行任何 I/O 操作，但它会记录每个与文件相关联的事件以供后续处理。

::

	-- file: ch15/WriterIO.hs
	data Event = Open FilePath IOMode
			   | Put String String
			   | Close String
			   | GetContents String
				 deriving (Show)

虽然在 :ref:`using-a-new-monad-show-your-work` 中已经开发了一个 ``Logger`` 类型，但这里我们将使用标准的、更广泛的 ``Writer`` monad。和其它 ``mtl`` monad 类似， ``Writer`` 提供的 API 将在一个类型类中被定义，也就是接下来要展示的 ``MonadWriter`` 。``MonadWriter`` 最有用的方法是 ``tell`` ，这个方法记录了一个值。

::

	ghci> :m +Control.Monad.Writer
	ghci> :type tell
	tell :: (MonadWriter w m) => w -> m ()
	
虽然 ``tell`` 方法可以记录任意类型的 ``Monoid`` ，但是因为列表的类型是 ``Monoid`` ，所以 ``tell`` 方法将记录一个由 ``Event`` 构成的列表。

尽管我们可以让 ``Writer [Event]`` 成为 ``MonadHandle`` 的一个实例，但一个更廉价也更安全的做法是编写一个特殊的 monad ，并且要做到这一点也比较容易。

::

	-- file: ch15/WriterIO.hs
	newtype WriterIO a = W { runW :: Writer [Event] a }
		deriving (Monad, MonadWriter [Event])

执行函数首先会移除我们之前添加的 ``newtype`` 包装器，然后再调用普通 ``Writer`` monad 的执行函数。

::

	-- file: ch15/WriterIO.hs
	runWriterIO :: WriterIO a -> (a, [Event])
	runWriterIO = runWriter . runW

当我们在 **ghci** 中执行这段代码的时候，它将反馈给我们一份日志，这份日志记录了函数对文件所做的行为。

::

	ghci> :load WriterIO
	[1 of 3] Compiling MonadHandle      ( MonadHandle.hs, interpreted )
	[2 of 3] Compiling SafeHello        ( SafeHello.hs, interpreted )
	[3 of 3] Compiling WriterIO         ( WriterIO.hs, interpreted )
	Ok, modules loaded: SafeHello, MonadHandle, WriterIO.
	ghci> runWriterIO (safeHello "foo")
	((),[Open "foo" WriteMode,Put "foo" "hello world",Put "foo" "\n",Close "foo"])
	
.. _the-writer-monad-and-lists:

Writer monad 和 列表
^^^^^^^^^^^^^^^^^^^^

每当我们使用 ``tell`` 方法时， ``Writer`` monad 都会调用 monoid 的 ``mappend`` 函数。因为列表的 ``mappend`` 动作是 ``(++)`` ，而不断重复附加操作是非常浪费资源的，所以在实际使用 ``Writer`` 时，列表并不是一个很好的选择。在上面的实例中，我们纯粹是为了追求简单才使用了列表。

在生产代码中，如果你想使用 ``Writer`` monad ，并且需要类似列表的行为，那么你应当选择那些在执行附加操作时性能更优的类型。在 :ref:`taking-advantage-of-functions-as-data` 中介绍过的差异列表就是一个这样的类型。你不需要实现自己的差异列表：Haskell 包数据库 Hackage 提供了一个调试好的库，你可以直接下载使用。除此之外，你可以使用 ``Data.Sequence`` 模块中的 ``Seq`` 类型，我们在 :ref:`general-purpose-sequences` 中介绍过这个类型。

.. _arbitrary-io-revisited:

任意 I/O 访问
^^^^^^^^^^^^^

在使用类型类方法限制 ``IO`` 的同时，我们可能还会希望继续保留执行任意 I/O 操作的能力。为此，我们可以尝试将 ``MonadIO`` 作为约束添加到类型类里面。

::

	-- file: ch15/MonadHandleIO.hs
	class (MonadHandle h m, MonadIO m) => MonadHandleIO h m | m -> h

	instance MonadHandleIO System.IO.Handle IO

	tidierHello :: (MonadHandleIO h m) => FilePath -> m ()
	tidierHello path = do
	  safeHello path
	  liftIO (removeFile path)

但是这种方法会导致一个问题：添加 ``MonadIO`` 约束将使得我们无法再判断一个测试是否会带有副作用，我们也因此失去了在纯粹的环境中测试代码的能力。另一种方法是调整这个约束的作用域，使它只影响那些真正需要执行 I/O 操作的函数，而非所有函数。

::

	-- file: ch15/MonadHandleIO.hs
	tidyHello :: (MonadIO m, MonadHandle h m) => FilePath -> m ()
	tidyHello path = do
	  safeHello path
	  liftIO (removeFile path)

我们可以对不受 ``MonadIO`` 约束的函数使用纯属性测试，对其余的函数使用传统的单元测试。

遗憾的是，这种做法只不过是将一个问题换成了另一个问题：只受 ``MonadHandle`` 约束的代码将无法调用同时受 ``MonadIO`` 和 ``MonadHandle`` 约束的代码。如果我们在 ``MonadHandle`` 约束的代码内部发现了这个问题，那么我们就必须在引发这个问题的所有代码路径上都加上 ``MonadIO`` 约束。

允许执行任意 I/O 操作是有风险的，而且这么做对我们开发、测试代码的流程都会有巨大的影响。相比放宽对代码行为的限制，我们通常会追求更清晰的代码逻辑和更容易的测试环境。
	  
练习
^^^^

1. 使用 Quick Check，为 ``MonadHandle`` monad 中的一个动作编写一个测试，观察它是否尝试向一个未打开的文件句柄写入。在 ``safeHello`` 下尝试。

2. 编写一个试图向已关闭句柄写入的动作。你的测试捕获到这个问题了吗？

3. 在表单编码的字符串中，相同的键可能出现数次，每个键具有或不具有对应的值，例如 ``key&key=1&key=2`` 。你会用什么类型来表示这类字符串中和键相关联的值？编写一个正确捕获所有信息的解析器。