Цепочка методов против оператора |› Pipe

Конвейерная обработка поддерживает вывод типов F# слева направо. a.GroupBy требует, чтобы тип a уже был известен как seq<_>, тогда как a |> Seq.groupBy сам выводит a как seq<_>. Следующая функция:

let increment items = items |> Seq.map (fun i -> i + 1)

требует, чтобы аннотация типа была написана с использованием LINQ:

let increment (items:seq<_>) = items.Select(fun x -> x + 1)

Когда вы освоитесь с функциональным стилем, вы найдете способы сделать свой код более кратким. Например, предыдущую функцию можно сократить до:

let increment = Seq.map ((+) 1)

Другие уже объяснили большую часть различий между двумя стилями. С моей точки зрения, наиболее важным является вывод типов (упомянутый Дэниелом), который лучше работает с идиоматическим стилем F#, основанным на конвейерной обработке и таких функциях, как List.map.

Еще одно отличие заключается в том, что при использовании стиля F# вы можете легче увидеть, какая часть вычислений выполняется лениво, когда вычисление принудительно и т. д., поскольку вы можете комбинировать функции для IEnumerable<_> (называемые Seq) и функции для списков или массивов:

let foo input =
  input 
  |> Array.map (fun a -> a) // Takes array and returns array (more efficient)
  |> Seq.windowed 2         // Create lazy sliding window
  |> Seq.take 10            // Take sequence of first 10 elements
  |> Array.ofSeq            // Convert back to array

Я также нахожу оператор |> синтаксически более удобным, потому что я никогда не знаю, как правильно сделать отступ в коде, использующем .Foo, особенно где поставить точку. С другой стороны, |> имеет устоявшийся стиль программирования на F#.

В общем, я рекомендую использовать стиль |>, потому что он "более стандартный". Нет ничего плохого в использовании стиля C# в F#, но вы можете обнаружить, что написание кода в более идиоматическом стиле упрощает использование некоторых интересных концепций функционального программирования, которые лучше работают в F#, чем в C#.

На самом деле оператор канала ничего не делает, кроме как меняет местами функцию и аргумент, насколько мне известно, нет никакой разницы между f1 (f2 3) и 3 |> f2 |> f1, кроме того, что последний легче читать, когда вы много связываете вместе.

редактировать: это фактически определено так: let inline (|>) x f = f x.

Я предполагаю, что причина, по которой вы склонны видеть подход List.map больше, чем Linq, заключается в том, что в OCaml (предшественнике F#) эти операторы всегда были там, поэтому этот стиль кодирования действительно укоренился в том, как думают функциональные программисты. Список — это очень простая концепция в F#, она немного отличается от IEnumerable (это ближе к Seq).

Linq — это в значительной степени попытка перенести эти концепции функционального программирования на C# и VB. Итак, они есть на платформе .Net и поэтому доступны, но в F# они избыточны.

Кроме того, List.map — очень простая операция, в то время как подход Linq включает всю структуру с ленивой оценкой и т. д., что приводит к некоторым накладным расходам. Но я не думаю, что это будет иметь существенное значение, пока вы действительно не будете использовать его часто. Я слышал в каком-то разговоре, что причина, по которой компилятор C# больше не использует Linq, заключается в этой причине, но в обычной жизни вы вряд ли заметите.

В общем, делайте то, что вам удобнее, здесь нет правильного или неправильного. Лично я бы выбрал операторы списка, потому что они более стандартны в «идиоматическом» F#.

GJ

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

open System
open System.Linq
open Microsoft.FSharp.Collections

let a = ["a", 2; "b", 1; "a", 42; ]

let c = a |> Seq.groupBy (fst) |> Seq.map (fun (x,y) -> x, Seq.length y)

//Type inference will not work here
//let d1 = a.GroupBy(fun x -> fst x).Select(fun x -> x.Key, x.Count())

//So we need this instead
let d2 = a.GroupBy(fun x -> fst x).Select(fun (x : IGrouping<string, (string * int)>) -> x.Key, x.Count())

for i in c do
    Console.WriteLine(i)

for i in d2 do
    Console.WriteLine(i)

Насколько я понимаю, оператор F# |> был введен для того, чтобы операции последовательности выглядели как запросы LINQ, или, лучше, чтобы они были похожи на цепочку методов расширения C#. List.map и filter, по сути, являются функциями в «функциональном» смысле: получить последовательность и f на вход, вернуть последовательность. Без канала вариант F# будет

filter(fun(x) -> x > 10, map(fun(x) -> x*3, a))

Обратите внимание, что визуально порядок функций обратный (приложения все еще в том же порядке): с |> они выглядят более «естественно» или, лучше, они больше похожи на вариант C#. C# достигает той же цели с помощью методов расширения: помните, что метод C# на самом деле

Enumerable.Where(Enumerable.Select(a, f1), f2)

Enumerable.Select — это функция, в которой первым параметром является «this IEnumerable», который используется компилятором для преобразования его в a.Select... В конце концов, это языковые средства (реализованные посредством преобразований компилятора в C#, и использование операторов и частичного применения в F#), чтобы сделать вложенные вызовы функций более похожими на цепочку преобразований.