Состав (.) Haskell по сравнению с каналом F# передает оператор (|>)
Также обратите внимание, что большая часть повышения является шаблонами, так не требует здания
(просто включают корректные заголовочные файлы).
Несколько частей, которые действительно требуют здания, являются дополнительными:
Они могут каждый быть созданы, независимо таким образом предотвратив ненужное чрезмерное увеличение размера для ненужного кода.
5 ответов
Я немного спекулятивен ...
Культура : Я думаю, что |> - важный оператор в «культуре» F #, и, возможно, аналогично . для Haskell. F # имеет оператор композиции функций << , но я думаю, что сообщество F # имеет тенденцию использовать безточечный стиль меньше, чем сообщество Haskell.
Языковые различия : Я не знаю 'недостаточно знаю об обоих языках для сравнения, но, возможно, правила обобщения let-привязок достаточно разные, чтобы повлиять на это. Например, я знаю, что в F # иногда запись
let f = exp
не компилируется, и вам нужно явное преобразование eta:
let f x = (exp) x // or x |> exp
для компиляции. Это также уводит людей от бессмысленного / композиционного стиля в сторону конвейерного стиля. Кроме того, вывод типа F # иногда требует конвейерной обработки, так что известный тип появляется слева (см. здесь ).
(Лично я считаю, что стиль без точек нечитаем, но я полагаю, что каждый новый / другой эта вещь кажется нечитаемой, пока вы к ней не привыкнете.)
Я думаю, что оба потенциально жизнеспособны на любом языке, и история / культура / случайность могут определить, почему каждое сообщество обосновалось на другом «аттракторе».
В F # (|>) важен из-за проверки типов слева направо. Например:
List.map (fun x -> x.Value) xs
обычно не проверяет тип, потому что даже если известен тип xs , тип аргумента x лямбда-выражения в то время неизвестен. проверка типов видит это, поэтому он не знает, как разрешить x.Value .
Напротив,
xs |> List.map (fun x -> x.Value)
будет работать нормально, потому что тип xs приведет к известен тип x .
Проверка типов слева направо требуется из-за разрешения имен, задействованного в таких конструкциях, как x.Value . Саймон Пейтон Джонс написал предложение о добавлении подобного типа разрешения имен в Haskell, но он предлагает вместо этого использовать локальные ограничения, чтобы отслеживать, поддерживает ли тип конкретную операцию или нет. Итак, в первом примере требование о том, что x требует свойства Value , будет перенесено до тех пор, пока не будет обнаружено xs и это требование не будет разрешено. Однако это усложняет систему типов.
Больше предположений, на этот раз со стороны преимущественно Haskell ...
($) - это замена (|>) , и его использование довольно часто встречается, когда вы не можете писать бессмысленный код. Итак, основная причина того, что (|>) не используется в Haskell, заключается в том, что его место уже занял ($) .
Кроме того, исходя из небольшого опыта F #, Я думаю, что (|>) настолько популярен в коде F #, потому что он напоминает структуру Subject.Verb (Object) объектно-ориентированного программирования. Поскольку F # нацелен на плавную функциональную / объектно-ориентированную интеграцию, Subject |> Verb Object - довольно плавный переход для новых функциональных программистов.
Лично мне тоже нравится думать слева направо, поэтому я используйте (|>) в Haskell, но я не думаю, что многие другие люди это делают.
Я видел >>> , который использовался для переворота (.) , и я сам часто использую его, особенно для длинных цепей, которые лучше всего подходят понимал слева направо.
>>> фактически взят из Control.Arrow и работает не только с функциями.
Композиция слева направо в Haskell
Некоторые люди также используют стиль слева направо (передача сообщений) в Haskell. См., Например, библиотеку mps на сайте Hackage. Пример:
euler_1 = ( [3,6..999] ++ [5,10..999] ).unique.sum
Я думаю, что в некоторых ситуациях этот стиль выглядит хорошо, но его труднее читать (нужно знать библиотеку и все ее операторы, переопределенный (.) тоже беспокоит).
Есть также операторы композиции слева направо и справа налево в Control.Category , части базового пакета. Сравните >>> и <<< соответственно:
ghci> :m + Control.Category
ghci> let f = (+2) ; g = (*3) in map ($1) [f >>> g, f <<< g]
[9,5]
Иногда есть веская причина предпочесть композицию слева направо: порядок оценки следует порядку чтения.