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

Ответ 1

Ниже перечислены краткие описания списков в Глава 12.

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

Итак,

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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