В дополнение к предыдущему посту.
Двумя главными преимуществами таких простых пайплайнов адепты F# называют:
а) Автоматический вывод типов, действующий слева направо, что позволяет при использовании
x |> someExpression
писать в выражении someExpression поля и методы x (такие как x.Smth), если тип х уже был известен.
Так, если есть последовательность FileInfo, то если попытаться из каждого ее элемента выделить только имя файла таким макаром:
let getNames
(myFileInfos: FileInfo
seq) = Seq.
map (fun x
-> x.
Name) myFileInfos
то компилятор заругается, поскольку при обработке лямбды он понятия не имеет, какой тип может иметь ее входящий параметр, определить этого не может, и совершенно не верит, что этот параметр в общем случае имеет свойство Name.
Ситуация в корне меняется с применением пайплайна:
let getNames
(myFileInfos: FileInfo
seq) = myFileInfos
|> Seq.
map (fun x
-> x.
Name) Здесь, благодаря обработке слева направо, тип элемента последовательности уже строго определен на момент описания лямбды, и компилятор это скушает, еще и облизнется.
б) Второе преимущество вытекает из первого: возможность переделки нагруженных скобками ОО-выражений с вызовами методов удобочитаемыми и простыми последовательностями функциональных вызовов.
К примеру, в своем проекте-песочнице, где я набиваю разные заковыристые функции на F# по мере чтения "Expert F#" и тематических блогов, результаты всех функций отображаются в простом окошке WPF. Примерно так:
let test (textBox: RichTextBox) number answer =
let run x = Run(x)
let bold x = Bold(x)
let paragraph x = Paragraph(x)
let add x = textBox.Document.Blocks.Add(x)
number |> sprintf "Testcase %d:" |> run |> bold |> paragraph |> add
answer |> sprintf "%A" |> run |> paragraph |> add
А теперь сравните с вот этой прелестью, сильно смахивающей на Лисп:
let test (textBox: RichTextBox) number answer =
textBox.Document.Blocks.Add(Paragraph(Bold(Run(sprintf "Testcase %d:" number))))
textBox.Document.Blocks.Add(Paragraph(Run(sprintf "%A" answer)))
Не спорю, оно короче. Но при чуть более обширной схеме XAML уже пришлось бы сильно поднапрячься, чтобы выяснить, что в чем расположено. Ну или другой вариант: сгенерировать сразу большую строку XAML-a, вформатировав туда нужные данные, и скормить ее парсеру.
Но зачем? Если можно так, как в первом случае :)
Вообще-то, оба аргумента покрывают одну и ту же проблему: функции F# и методы .NET, на котором оно построено, имеют разную природу, синтаксис вызова и парадигму. И потому при переходе из одного мира в другой, и обратно, приходится порою чесать себе затылок.
"Запад есть запад, Восток есть Восток, и им не сойтись никогда". ©