Склад функцій Haskell (.) Та функціональних застосувань ($): правильне використання

Я читав Haskell в реальному світі , і я наближаюся до кінця, але питання стилю насміхувало, що стосується операторів (.)та ($)операторів.

Коли ви пишете функцію, що є складом інших функцій, ви записуєте її так:

f = g . h

Але коли ви застосовуєте щось до кінця цих функцій, я записую це так:

k = a $ b $ c $ value

Але книга написала б це так:

k = a . b . c $ value

Тепер для мене вони виглядають функціонально рівнозначними, вони роблять точно те саме в моїх очах. Однак чим більше я дивлюся, тим більше я бачу людей, що пишуть свої функції таким чином, як це робить книга: складати (.)спочатку, а потім лише в кінці використовувати, ($)щоб додати значення для оцінки партії (ніхто не робить це з багатьма доларовими композиціями) .

Чи є причина використання книг набагато кращою, ніж використання всіх ($)символів? Або є якась найкраща практика, яку я не отримую? Або це зайве, і я взагалі не повинен про це турбуватися?

Я думаю, що можу відповісти на це авторитетом.

Чи є причина використання книг набагато кращим, ніж використання усіх ($) символів?

Особливих причин немає. Ми з Брайаном воліємо зменшити шум лінії. .тихіше, ніж $. В результаті книга використовує f . g . h $ xсинтаксис.

Вони справді рівноцінні: майте на увазі, що $оператор, по суті, нічого не робить. f $ xоцінює до f x. Метою $є поведінка його непохитності: право-асоціативна та мінімальна пріоритетність. Видалення $та використання круглих дужок для групування замість пріоритету інфікування, фрагменти коду виглядають так:

k = a (b (c (value)))

і

k = (a . b . c) value

Причина віддати перевагу .версії над $версією - це та сама причина переваги обох над самою вище в дужці версією: естетична привабливість.

Хоча, хтось може задатися питанням, чи використання операторів infix замість дужок базується на підсвідомому спонуканні уникати будь-якої можливої ​​подібності з Lisp (просто жартую ... я думаю?).

Додам, що в f . g $ x, f . gце значуща синтаксична одиниця.

Тим часом, в Росії f $ g $ x, f $ gце не змістовна одиниця. Ланцюг $, можливо , більш важливо - першим отримати результат gз x, а потім зробити fйого, а потім зробити fooйого, то і т.д.

Тим часом ланцюг ., мабуть, декларативніший, і в деякому сенсі наближений до орієнтованого на потік даних потоку даних - складають ряд функцій і в кінцевому рахунку застосовують їх до чогось.

Для мене, я думаю, що відповідь - це (а) акуратність, як сказав Дон ; і (б) я виявляю, що коли я редагую код, моя функція може закінчитися безточним стилем, і тоді все, що мені потрібно зробити, - це видалити останнє, $а не повертатися назад і змінити все. Незначний момент, звичайно, але нікчемність.

У цій темі haskell-cafe є цікаве обговорення цього питання . По- видимому , є меншість точка зору , яка вважає , що право асоціативності $є «просто неправильно» , і вибір f . g . h $ xбільш ніж f $ g $ h $ xодин з способів бічних крокової питання.

Це просто питання стилю. Однак те, як це робить книжка, має для мене більше сенсу. Він складає всі функції, а потім застосовує їх до значення.

Ваш метод просто виглядає дивно, а останній $непотрібний.

Однак це насправді не має значення. У Haskell зазвичай існує багато, багато правильних способів зробити те саме.

Я усвідомлюю, що це дуже давнє питання, але я думаю, що є ще одна причина цього, про яку не було сказано.

Якщо ви декларуєте нову функцію без точки f . g . h, значення, яке ви передаєте, буде застосовано автоматично. Однак якщо ти пишеш f $ g $ h , це не вийде.

Я думаю, що автор вважає за краще метод композиції в тому, що це призводить до належної практики створення функцій.