Не лякайтеся! Монада для читання насправді не така складна, і має справжню просту у використанні утиліту.
Є два способи наближення монади: ми можемо запитати
- Що монада робити ? Якими операціями він оснащений? Для чого це добре?
- Як здійснюється монада? Звідки воно виникає?
З першого підходу читацька монада є деяким абстрактним типом
data Reader env a
такий, що
-- Reader is a monad
instance Monad (Reader env)
-- and we have a function to get its environment
ask :: Reader env env
-- finally, we can run a Reader
runReader :: Reader env a -> env -> a
То як ми цим користуємося? Ну, читацька монада хороша для передачі (неявної) інформації конфігурації через обчислення.
Кожен раз, коли у вас є "константа" в обчисленні, яка вам потрібна в різних точках, але дійсно ви хотіли б мати можливість виконувати однакові обчислення з різними значеннями, тоді вам слід використовувати монаду читача.
Читальні монади також використовуються, щоб робити те, що люди називають введенням залежності . Наприклад, алгоритм negamax використовується часто (у високооптимізованих формах) для обчислення значення позиції в грі з двома гравцями. Сам алгоритм хоч і не байдуже, в яку гру ви граєте, за винятком того, що вам потрібно вміти визначати, які "наступні" позиції в грі, і вам потрібно вміти визначати, чи є поточна позиція перемогою.
import Control.Monad.Reader
data GameState = NotOver | FirstPlayerWin | SecondPlayerWin | Tie
data Game position
= Game {
getNext :: position -> [position],
getState :: position -> GameState
}
getNext' :: position -> Reader (Game position) [position]
getNext' position
= do game <- ask
return $ getNext game position
getState' :: position -> Reader (Game position) GameState
getState' position
= do game <- ask
return $ getState game position
negamax :: Double -> position -> Reader (Game position) Double
negamax color position
= do state <- getState' position
case state of
FirstPlayerWin -> return color
SecondPlayerWin -> return $ negate color
Tie -> return 0
NotOver -> do possible <- getNext' position
values <- mapM ((liftM negate) . negamax (negate color)) possible
return $ maximum values
Потім це буде працювати з будь-якою кінцевою, детермінованою двома гравцями.
Ця модель корисна навіть для речей, які насправді не є ін'єкцією залежності. Припустимо, що ви працюєте у фінансах, ви можете розробити складну логіку для ціноутворення активу (похідне слово), що все добре і добре, і ви можете обійтися без будь-яких смердючих монад. Але потім ви модифікуєте свою програму для роботи з кількома валютами. Потрібно мати можливість конвертувати між валютами на ходу. Ваша перша спроба - визначити функцію верхнього рівня
type CurrencyDict = Map CurrencyName Dollars
currencyDict :: CurrencyDict
щоб отримати спотові ціни. Ви можете зателефонувати цьому словнику у свій код .... але зачекайте! Це не вийде! Словник валюти є незмінним, тому він повинен бути однаковим не лише протягом вашої програми, але і з моменту його складання ! Так, що ти робиш? Що ж, одним із варіантів було б використання монарда Reader:
computePrice :: Reader CurrencyDict Dollars
computePrice
= do currencyDict <- ask
--insert computation here
Мабуть, самий класичний варіант використання - це втілення перекладачів. Але, перш ніж ми розглянемо це, нам потрібно ввести ще одну функцію
local :: (env -> env) -> Reader env a -> Reader env a
Гаразд, тому Haskell та інші функціональні мови базуються на обчисленні лямбда . Обчислення лямбда має синтаксис, який виглядає так
data Term = Apply Term Term | Lambda String Term | Var Term deriving (Show)
і ми хочемо написати оцінювача для цієї мови. Для цього нам потрібно буде відслідковувати середовище, що є переліком прив’язок, пов’язаних із термінами (насправді це буде закриття, тому що ми хочемо зробити статичне оцінювання).
newtype Env = Env ([(String, Closure)])
type Closure = (Term, Env)
Коли ми закінчимо, нам слід отримати значення (або помилку):
data Value = Lam String Closure | Failure String
Отже, давайте запишемо перекладача:
interp' :: Term -> Reader Env Value
--when we have a lambda term, we can just return it
interp' (Lambda nv t)
= do env <- ask
return $ Lam nv (t, env)
--when we run into a value, we look it up in the environment
interp' (Var v)
= do (Env env) <- ask
case lookup (show v) env of
-- if it is not in the environment we have a problem
Nothing -> return . Failure $ "unbound variable: " ++ (show v)
-- if it is in the environment, then we should interpret it
Just (term, env) -> local (const env) $ interp' term
--the complicated case is an application
interp' (Apply t1 t2)
= do v1 <- interp' t1
case v1 of
Failure s -> return (Failure s)
Lam nv clos -> local (\(Env ls) -> Env ((nv, clos) : ls)) $ interp' t2
--I guess not that complicated!
Нарешті, ми можемо використовувати його, передаючи тривіальне середовище:
interp :: Term -> Value
interp term = runReader (interp' term) (Env [])
І це все. Повністю функціональний перекладач обчислення лямбда.
Інший спосіб подумати над цим - запитати: як це реалізується? Відповідь полягає в тому, що читацька монада - це насправді одна з найпростіших та найелегантніших монард.
newtype Reader env a = Reader {runReader :: env -> a}
Зчитувач - просто фантазія назви функцій! Ми вже визначилися, runReaderщо робити з іншими частинами API? Що ж, Monadце також Functor:
instance Functor (Reader env) where
fmap f (Reader g) = Reader $ f . g
Тепер, щоб отримати монаду:
instance Monad (Reader env) where
return x = Reader (\_ -> x)
(Reader f) >>= g = Reader $ \x -> runReader (g (f x)) x
що не так страшно. askдійсно просто:
ask = Reader $ \x -> x
поки localце не так погано:
local f (Reader g) = Reader $ \x -> runReader g (f x)
Гаразд, тому читацька монада - це лише функція. Чому взагалі читач? Гарне питання. Насправді вам це не потрібно!
instance Functor ((->) env) where
fmap = (.)
instance Monad ((->) env) where
return = const
f >>= g = \x -> g (f x) x
Вони ще простіші. Більше того, askце просто idі localє лише функціональна композиція з порядком перемикання функцій!