В F # |>довольно часто используется оператор конвейерной передачи ,. Однако в Haskell я видел только использование композиции функций (.). Я понимаю, что они связаны , но есть ли языковая причина, по которой конвейерная передача не используется в Haskell, или это что-то еще?

Я немного рассуждаю ...

Культура : я считаю, что |>это важный оператор в «культуре» 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)структуру OO. Поскольку F # нацелен на плавную функциональную / объектно-ориентированную интеграцию, Subject |> Verb Objectэто довольно плавный переход для новых функциональных программистов.

Лично мне тоже нравится думать слева направо, поэтому я использую (|>)в Haskell, но не думаю, что многие другие люди это делают.

Я думаю, мы что-то путаем. Haskell ( .) эквивалентен F # ( >>). Не путать с F # ( |>), которое представляет собой просто инвертированное приложение функции и похоже на Haskell ( $) - наоборот:

let (>>) f g x = g (f x)
let (|>) x f = f x

Я считаю, что программисты на Haskell $часто его используют . Возможно, не так часто, как привыкли использовать программисты на F # |>. С другой стороны, некоторые ребята из F # >>до смешного используют: http://blogs.msdn.com/b/ashleyf/archive/2011/04/21/programming-is-pointless.aspx

Если вы хотите использовать F # |>в Haskell, тогда в Data.Function будет &оператор (с base 4.8.0.0).

Композиция слева направо в 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]

Иногда есть веская причина предпочесть композицию слева направо: порядок оценки следует порядку чтения.

Я видел, как >>>их использовали flip (.), и сам часто использую это, особенно для длинных цепочек, которые лучше всего понимать слева направо.

>>> на самом деле из Control.Arrow и работает не только с функциями.

Помимо стиля и культуры, это сводится к оптимизации дизайна языка для чистого или нечистого кода.

|>Оператор часто встречается в F # в основном потому , что это помогает скрыть два ограничения , которые появляются с преимущественно-нечистым кодом:

• Выведение типов слева направо без структурных подтипов.
• Ограничение стоимости.

Обратите внимание, что первое ограничение не существует в OCaml, потому что подтип является структурным, а не номинальным, поэтому структурный тип легко уточняется с помощью унификации по мере продвижения вывода типа.

Haskell идет на другой компромисс, предпочитая сосредоточиться на преимущественно чистом коде, где эти ограничения могут быть сняты.

Я думаю, что оператор F # pipe forward ( |>) должен vs ( & ) в haskell.

// pipe operator example in haskell

factorial :: (Eq a, Num a) =>  a -> a
factorial x =
  case x of
    1 -> 1
    _ -> x * factorial (x-1)

// terminal
ghic >> 5 & factorial & show

Если вам не нравится &оператор ( ), вы можете настроить его как F # или Elixir:

(|>) :: a -> (a -> b) -> b
(|>) x f = f x
infixl 1 |>

ghci>> 5 |> factorial |> show

Почему infixl 1 |>? См. Документ в Data-Function (&)

infixl = infix + левая ассоциативность

infixr = infix + правая ассоциативность

(.)

( .) означает композицию функций. Это означает (fg) (x) = f (g (x)) в Math.

foo = negate . (*3)

// ouput -3
ghci>> foo 1
// ouput -15
ghci>> foo 5

это равно

// (1)
foo x = negate (x * 3) 

или

// (2)
foo x = negate $ x * 3 

( $) также определяется в Data-Function ($) .

( .) используется для создания Hight Order Functionили closure in js. См. Пример:

// (1) use lamda expression to create a Hight Order Function
ghci> map (\x -> negate (abs x)) [5,-3,-6,7,-3,2,-19,24]  
[-5,-3,-6,-7,-3,-2,-19,-24]


// (2) use . operator to create a Hight Order Function
ghci> map (negate . abs) [5,-3,-6,7,-3,2,-19,24]  
[-5,-3,-6,-7,-3,-2,-19,-24]

Вау, меньше (код) лучше.

Сравните |>и.

ghci> 5 |> factorial |> show

// equals

ghci> (show . factorial) 5 

// equals

ghci> show . factorial $ 5 

Это разница между left —> rightи right —> left. ⊙﹏⊙ |||

Гуманизация

|>и &лучше чем.

так как

ghci> sum (replicate 5 (max 6.7 8.9))

// equals

ghci> 8.9 & max 6.7 & replicate 5 & sum

// equals

ghci> 8.9 |> max 6.7 |> replicate 5 |> sum

// equals

ghci> (sum . replicate 5 . max 6.7) 8.9

// equals

ghci> sum . replicate 5 . max 6.7 $ 8.9

Как функциональное программирование на объектно-ориентированном языке?

посетите http://reactivex.io/

ИТ поддержка :

• Java: RxJava
• JavaScript: RxJS
• C #: Rx.NET
• C # (Единство): UniRx
• Scala: RxScala
• Clojure: RxClojure
• C ++: RxCpp
• Lua: RxLua
• Рубин: Rx.rb
• Python: RxPY
• Перейти: RxGo
• Groovy: RxGroovy
• JRuby: RxJRuby
• Котлин: RxKotlin
• Swift: RxSwift
• PHP: RxPHP
• Эликсир: реактивный
• Дротик: RxDart

Это мой первый день, когда я пробую Haskell (после Rust и F #), и я смог определить оператор F # |>:

(|>) :: a -> (a -> b) -> b
(|>) x f = f x
infixl 0 |>

и вроде работает:

factorial x =
  case x of
    1 -> 1
    _ -> x * factorial (x-1)

main =     
    5 |> factorial |> print

Бьюсь об заклад, эксперт по Haskell может предложить вам еще лучшее решение.