Изучай Haskell во имя добра! (Липовача) - страница 291

:

>ghci> let newFocus = (myDisk, []) –: fsTo "pics" –: fsRename "cspi" –: fsUp

Мы спустились к каталогу >"pics", переименовали его, а затем поднялись обратно вверх.

Как насчёт функции, которая создаёт новый элемент в текущем каталоге? Встречайте:

>fsNewFile :: FSItem –> FSZipper –> FSZipper

>fsNewFile item (Folder folderName items, bs) =

>   (Folder folderName (item:items), bs)

Проще пареной репы! Обратите внимание, что если бы мы попытались добавить элемент, но фокусировались бы на файле, а не на каталоге, это привело бы к аварийному завершению программы.

Давайте добавим в наш каталог >"pics" файл, а затем поднимемся обратно к корню:

>ghci> let newFocus =

>   (myDisk, []) –: fsTo "pics" –: fsNewFile (File "heh.jpg" "лол") –: fsUp

Что действительно во всём этом здорово, так это то, что когда мы изменяем нашу файловую систему, наши изменения на самом деле не производятся на месте – напротив, функция возвращает совершенно новую файловую систему. Таким образом, мы имеем доступ к нашей прежней файловой системе (в данном случае >myDisk), а также к новой (первый компонент >newFocus).

Используя застёжки, мы бесплатно получаем контроль версий. Мы всегда можем обратиться к старым версиям структур данных даже после того, как изменили их. Это не уникальное свойство застёжек; оно характерно для языка Haskell в целом, потому что его структуры данных неизменяемы. При использовании застёжек, однако, мы получаем возможность легко и эффективно обходить наши структуры данных, так что неизменность структур данных языка Haskell действительно начинает сиять во всей красе!

Осторожнее – смотрите под ноги!

До сих пор при обходе наших структур данных – будь они бинарными деревьями, списками, или файловыми системами – нам не было дела до того, что мы прошагаем слишком далеко и упадём. Например, наша функция >goLeft принимает застёжку бинарного дерева и передвигает фокус на его левое поддерево:

>goLeft :: Zipper a –> Zipper a

>goLeft (Node x l r, bs) = (l, LeftCrumb x r:bs)

Но что если дерево, с которого мы сходим, является пустым? Что если это не значение >Node, а >Empty? В этом случае мы получили бы ошибку времени исполнения, потому что сопоставление с образцом завершилось бы неуспешно, а образец для обработки пустого дерева, у которого нет поддеревьев, мы не создавали.

До сих пор мы просто предполагали, что никогда не пытались бы навести фокус на левое поддерево пустого дерева, так как его левого поддерева просто не существует. Но переход к левому поддереву пустого дерева не имеет какого-либо смысла, и мы до сих пор это удачно игнорировали.