Являются ли списочные постижения основной частью Haskell?

Question

Я просмотрел различные ресурсы Haskell в Интернете, прежде чем купить книгу Real World Haskell. Будучи отличным в остальном, он, похоже, не содержит ничего о списках, которые я видел, упомянутых на различных сайтах, на которые я смотрел. Может ли это быть просто потому, что по какой-то причине они обычно не используются в хорошо написанном Haskell, или это нечто более сложное? Например, странно выглядящий синтаксис может быть просто объединением операторов, которых я еще не видел.

Answer 1

Понимание списка кратко упоминается в главе 12 .

Я использую комбинации карт и фильтров гораздо чаще, чем списочные в Haskell, но в Python я бы чаще использовал списочные. Так что я думаю, что это часть личного стиля.

Как только вы поймете, как использовать каждую часть понимания списка, что еще вы можете узнать в отношении понимания списка? У вас есть ваши входы, ваши условия / средства защиты и ваши приложения функций для возвращенного списка. Я действительно не вижу обоснованной необходимости в большом разделе о понимании списков в книге.

Answer 2

Haskell определяется наличием небольшого набора основных функций языка, окруженного богатым набором синтаксических вариантов. Понимание списков - один из вариантов, но они не дают ничего, чего не дает монадный сахар, на который RWH тратит всю книгу, создавая интуицию. Есть много случаев, когда Haskell предоставляет два синтаксиса для одной и той же вещи: пусть и где, стиль программирования, ориентированный на регистр и комбинатор, а также списки и монадный сахар.

Постижения списков были первоначально реализованы как монадные, факт, который изменился во время "великой революции мономорфизации '98" (он же Haskell '98). Фактически, дизайн LINQ на языках .NET во многом основан на более старом дизайне понимания монад. Понимание списков может быть гораздо более общим, чем оно есть, но оно было намеренно ограничено, чтобы облегчить понимание сообщений об ошибках.

Учитывая ограниченное количество бумаги, вы должны выбрать, какой материал подчеркнуть, и RWH по большей части избегает говорить о них, чтобы вы не попали в ловушку представления списков как чего-то особенного.

Тем не менее, есть краткое упоминание о них в главе 12. К этому моменту была сформирована достаточная интуиция для основополагающих концепций, что они на самом деле не представляют опасности.

В конце концов, название книги - Real World Haskell. Он хочет научить вас хорошим методам программирования в реальном мире. Многие Хаскелеры (не все) избегают составления списков, потому что нотация плохо масштабируется, и потому что в конечном итоге вы можете захотеть вернуться и модифицировать монадный преобразователь или что-то в этом роде и перезаписать целые серии кода понимания в монадическом стиль в любом случае.

[Обновление: теперь, когда GHC восстановил понимание монады это возражение не так сильно, как раньше. Вы можете получить некоторые интересные новые функциональные возможности из них.]

Answer 3

Постижения списков появляются в основном в небольших примерах обработки списков, многие из которых предназначены для явного математического характера. Когда вы начинаете изучать более крупные приложения, такие как Real World Haskell , обработка списка пропорционально занимает гораздо меньшую часть кода. И, как уже отмечалось, часто столь же удобно использовать map, filter, fold, zip и т. Д., Как и использование списка.

So

• В реальной программе на Haskell только небольшая часть кода обрабатывает списки.

• Лишь небольшая часть кода Haskell для обработки списков получается значительно приятнее при написании с использованием понимания списков.

Почти все составления списков, которые я пишу, оказываются производящими списки пар. Однако я не уверен, что что-то следует в этом прочесть.

Answer 4

Понятия списков - синтаксический сахар для связывания (как в привязке монады) списков.

Другой синтаксический сахар для этого - нотация. Имхо, это лучше, и большой плюс в том, что он работает для всех монад.

Если бы списочных пониманий не было, я думаю, что было бы меньше, чему можно научиться, и ничего не было бы потеряно (вместо этого можно использовать do-notation).

Аргумент в пользу понимания списка состоит в том, что для пользователя стало бы понятнее, что это список. Имхо тип подписи будет работать лучше для этого.

Answer 5

Я вижу три упоминания понимания списка в RWH.