Skład funkcji Haskella (.) I idiomy aplikacji funkcji ($): prawidłowe użycie

Czytałem Real World Haskell i zbliżam się do końca, ale kwestia stylu mnie dręczy z operatorami (.)i ($).

Kiedy piszesz funkcję będącą kompozycją innych funkcji, piszesz ją tak:

f = g . h

Ale kiedy zastosujesz coś na końcu tych funkcji, piszę to w ten sposób:

k = a $ b $ c $ value

Ale książka napisałaby to tak:

k = a . b . c $ value

Dla mnie wyglądają na równoważne funkcjonalnie, robią dokładnie to samo w moich oczach. Jednak im więcej patrzę, tym częściej widzę ludzi piszących swoje funkcje w sposób, w jaki robi to książka: (.)najpierw komponuj, a dopiero na końcu użyj, ($)aby dodać wartość, aby ocenić partię (nikt nie robi tego z wieloma kompozycjami dolarowymi) .

Czy jest jakiś powód, by używać książek w sposób znacznie lepszy niż używanie wszystkich ($)symboli? Czy jest tu jakaś najlepsza praktyka, której nie rozumiem? A może jest to zbędne i nie powinienem się tym w ogóle martwić?

Chyba mogę odpowiedzieć na to autorytetem.

Czy istnieje powód, aby używać książek w sposób znacznie lepszy niż używanie wszystkich symboli ($)?

Nie ma specjalnego powodu. Bryan i ja wolimy redukować szumy liniowe. .jest cichszy niż $. W rezultacie książka używa f . g . h $ xskładni.

W istocie są równoważne: pamiętaj, że $operator zasadniczo nic nie robi. f $ xocenia do f x. Celem $jest jego zachowanie związane ze stałością: prawostronna asocjacja i minimalny priorytet. Usunięcie $i użycie nawiasów do grupowania zamiast pierwszeństwa wrostków, fragmenty kodu wyglądają następująco:

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

i

k = (a . b . c) value

Powodem, dla którego preferujemy .wersję nad $wersją, jest ten sam powód, dla którego preferujemy obie wersje powyżej bardzo ujętej w nawiasy wersji: atrakcyjność estetyczna.

Chociaż niektórzy mogą się zastanawiać, czy użycie operatorów wrostków zamiast nawiasów jest oparte na jakiejś podświadomej chęci uniknięcia jakiegokolwiek możliwego podobieństwa do Lispa (tylko żartuję ... myślę?).

Dodam, że w f . g $ x, f . gjest znaczącą jednostką składniową.

Tymczasem w f $ g $ x, f $ gnie jest znacząca jednostka. Łańcuch $jest zapewne bardziej konieczne - najpierw uzyskać wynik gz x, następnie zrobić fz nim, a następnie zrobić fooz nim, potem itp

Tymczasem łańcuch .jest prawdopodobnie bardziej deklaratywny iw pewnym sensie bliższy widokowi skoncentrowanemu na przepływie danych - skomponuj serię funkcji i ostatecznie zastosuj je do czegoś.

Myślę, że dla mnie odpowiedzią jest (a) porządek, jak powiedział Don ; i (b) stwierdzam, że kiedy edytuję kod, moja funkcja może skończyć się w stylu bez punktów, a wtedy wszystko, co muszę zrobić, to usunąć ostatnią, $zamiast cofać się i zmieniać wszystko. Niewątpliwie drobna uwaga, ale drobiazg.

Jest interesująca dyskusja na ten temat w tym wątku haskell-cafe . Podobno istnieje mniejszość, która posiada punkt widzenia, że prawo asocjatywność o $to „po prostu źle” , a następnie wybierając f . g . h $ xna f $ g $ h $ xto jeden sposób side-stepping problem.

To tylko kwestia stylu. Jednak sposób, w jaki robi to książka, ma dla mnie większy sens. Składa wszystkie funkcje, a następnie stosuje je do wartości.

Twoja metoda po prostu wygląda dziwnie, a ostatnia $jest niepotrzebna.

Jednak to naprawdę nie ma znaczenia. W Haskell jest zwykle wiele, wiele poprawnych sposobów na zrobienie tego samego.

Zdaję sobie sprawę, że to bardzo stare pytanie, ale myślę, że jest inny powód, o którym nie wspomniano.

Jeśli deklarujesz nową funkcję bez punktów f . g . h, wartość, którą przekazujesz, zostanie zastosowana automatycznie. Jeśli jednak napiszesz f $ g $ h, to nie zadziała.

Myślę, że powodem, dla którego autor preferuje metodę kompozycji, jest to, że prowadzi ona do dobrej praktyki budowania funkcji.