Идиомы композиции (.) И приложения ($) функции Haskell: правильное использование
Я читал Real World на Haskell, и я близок к концу, но вопрос стиля меня теребил (.) а также ($) операторы.
Когда вы пишете функцию, которая является композицией других функций, вы пишете это так:
f = g . h
Но когда вы применяете что-то к концу этих функций, я пишу это так:
k = a $ b $ c $ value
Но книга напишет это так:
k = a . b . c $ value
Теперь, для меня они выглядят функционально эквивалентными, они делают то же самое в моих глазах. Однако чем больше я смотрю, тем больше я вижу людей, пишущих свои функции так, как это делает книга: сочинять с (.) сначала, а потом только в конце использования ($) добавить значение для оценки лота (никто не делает это со многими долларовыми композициями).
Есть ли причина, по которой книги лучше использовать, чем все ($) символы? Или есть лучшая практика, которую я не получаю? Или это излишне, и мне вообще не стоит об этом беспокоиться?
7 ответов
Я думаю, что я могу ответить на это от власти.
Есть ли какая-то причина, по которой книги лучше использовать, чем все символы ($)?
Там нет особой причины. Брайан и я оба предпочитаем уменьшать шум в линии. . тише чем $, В результате книга использует f . g . h $ x синтаксис.
Они действительно эквивалентны: имейте в виду, что $ Оператор, по сути, ничего не делает. f $ x оценивает f x, Цель $ является его поведением фиксированности: право-ассоциативный и минимальный приоритет. Удаление $ и используя скобки для группировки вместо инфиксного приоритета, фрагменты кода выглядят так:
k = a (b (c (value)))
а также
k = (a . b . c) value
Причина предпочтения . версия над $ версия является той же самой причиной, чтобы отдать предпочтение обеим версиям, указанным выше в скобках: эстетическая привлекательность.
Хотя некоторые могут задаться вопросом, основано ли на использовании инфиксных операторов вместо скобок какое-то подсознательное побуждение избегать какого-либо возможного сходства с Лиспом (шучу... я думаю?).
Я бы добавил это в f . g $ x, f . g является значимой синтаксической единицей.
Между тем в f $ g $ x, f $ g не значимая единица. Цепь $ возможно, более настоятельным - сначала получить результат g из xтогда делай f к этому, тогда делай foo к этому, то и т.д.
Тем временем цепочка . возможно, является более декларативным и в некотором смысле ближе к представлению, ориентированному на поток данных, - составьте ряд функций и в конечном итоге примените их к чему-либо.
Для меня, я думаю, ответ: а) опрятность, как сказал Дон; и (б) я обнаружил, что когда я редактирую код, моя функция может оказаться в стиле без точек, и тогда все, что мне нужно сделать, это удалить последний $ вместо того, чтобы возвращаться и менять все. Незначительный момент, конечно, но тонкость.
В этой ветке haskell-cafe есть интересное обсуждение этого вопроса. Очевидно, существует точка зрения меньшинства, которая считает, что правильная ассоциативность $ "просто неправильно", и выбор f . g . h $ x над f $ g $ h $ x это один из способов обойти проблему.
Это просто вопрос стиля. Однако способ, которым книга делает это, имеет больше смысла для меня. Составляет все функции, а затем применяет его к значению.
Ваш метод выглядит просто странно, и последний $ не нужно
Однако это действительно не имеет значения. В Хаскеле обычно есть много правильных способов сделать то же самое.
Я понимаю, что это очень старый вопрос, но я думаю, что есть еще одна причина, которая не была упомянута.
Если вы объявляете новую бессмысленную функцию f . g . hзначение, которое вы передадите, будет применено автоматически. Тем не менее, если вы пишете f $ g $ h, она не будет работать.
Я думаю, что причина, по которой автор предпочитает метод композиции, заключается в том, что он приводит к хорошей практике построения функций.