In F#, use of the the pipe-forward operator (|>) is pretty common. However, in Haskell I've only ever seen function composition (.) being used. I understand that they are related, but is there a language reason that pipe-forward isn't used in Haskell or is it something else?
views:
933answers:
5
+18
A:
I am being a little speculative...
Culture: I think (|>) is an important operator in the F# "culture", and perhaps similarly with (.) for Haskell. F# has a function composition operator (<<) but I think the F# community tends to use points-free style less than the Haskell community.
Language differences: I don't know enough about both languages to compare, but perhaps the rules for generalizing let-bindings are sufficiently different as to affect this. For example, I know in F# sometimes writing
let f = exp
will not compile, and you need explicit eta-conversion:
let f x = (exp) x // or x |> exp
to make it compile. This also steers people away from points-free/compositional style, and towards the pipelining style. Also, F# type inference sometimes demands pipelining, so that a known type appears on the left (see here).
(Personally, I find points-free style unreadable, but I suppose every new/different thing seems unreadable until you become accustomed to it.)
I think both are potentially viable in either language, and history/culture/accident may define why each community settled at a different "attractor".
Brian
2009-09-21 22:26:15
I agree with the cultural differences. Traditional Haskell makes use of `.` and `$`, so people continue to use them.
Amuck
2009-09-21 22:35:08
Point free is sometimes more readable than pointful, sometimes less. I generally use it in the argument to functions like map and filter, to avoid having a lambda cluttering things up. I sometimes use it in top-level functions too, but less often and only when its something straightforward.
Paul Johnson
2009-09-22 18:28:48
I don't see much culture in it, in the sense that there simply isn't much of a choice in the matter as far as F# is concerned (for the reasons you and Ganesh mention). So I'd say that both are viable in Haskell, but F# is definitely much better equipped for using the pipeline operator.
Kurt Schelfthout
2009-10-01 15:00:14
+6
A:
More speculation, this time from the predominantly Haskell side...
($) is the flip of (|>), and its use is quite common when you can't write point-free code. So the main reason that (|>) not used in Haskell is that its place is already taken by ($).
Also, speaking from a bit of F# experience, I think (|>) is so popular in F# code because it resembles the Subject.Verb(Object) structure of OO. Since F# is aiming for a smooth functional/OO integration, Subject |> Verb Object is a pretty smooth transition for new functional programmers.
Personally, I like thinking left-to-right too, so I use (|>) in Haskell, but I don't think many other people do.
Nathan Sanders
2009-09-22 06:57:25
Hi Nathan, is "flip ($)" predefined anywhere in the Haskell platform? The name "(|>)" is already defined in Data.Sequence with another meaning. If not already defined, what do you call it? I'm thinking of going with "($>) = flip ($)"
mattbh
2010-06-14 06:23:14
@mattbh: Not that I can find with Hoogle. I didn't know about `Data.Sequence.|>`, but `$>` looks reasonable to avoid conflicts there. Honestly, there are only so many good-looking operators, so I would just use `|>` for both and manage conflicts on a case-by-case basis. (Also I would be tempted to just alias `Data.Sequence.|>` as `snoc`)
Nathan Sanders
2010-06-14 13:21:48
+19
A:
In F# (|>) is important because of the left-to-right typechecking. For example:
List.map (fun x -> x.Value) xs
generally won't typecheck, because even if the type of xs is known, the type of the argument x to the lambda isn't known at the time the typechecker sees it, so it doesn't know how to resolve x.Value.
In contrast
xs |> List.map (fun x -> x.Value)
will work fine, because the type of xs will lead to the type of x being known.
The left-to-right typechecking is required because of the name resolution involved in constructs like x.Value. Simon Peyton Jones has written a proposal for adding a similar kind of name resolution to Haskell, but he suggests using local constraints to track whether a type supports a particular operation or not, instead. So in the first sample the requirement that x needs a Value property would be carried forward until xs was seen and this requirement could be resolved. This does complicate the type system, though.
Ganesh Sittampalam
2009-09-22 10:12:12
Interesting this is that there is (<|) operator similar to (.) in Haskell with the same direction of data right-to-left. But how will work type resolution for it?
The_Ghost
2009-09-24 13:25:38
(<|) is actually similar to Haskell's ($).Left-to-right typechecking is only required for resolving things like .Value, so (<|) works fine in other scenarios, or if you use explicit type annotations.
Ganesh Sittampalam
2009-12-18 08:39:27
+6
A:
I have seen >>> being used for flip (.), and I often use that myself, especially for long chains that are best understood left-to-right.
>>> is actually from Control.Arrow, and works on more than just functions.
spookylukey
2009-10-02 00:35:47
+1
A:
Left-to-right composition in Haskell
Some people use left-to-right (message-passing) style in Haskell too. See, for example, mps library on Hackage. An example:
euler_1 = ( [3,6..999] ++ [5,10..999] ).unique.sum
I think this style looks nice in some situations, but it's harder to read (one needs to know the library and all its operators, the redefined (.) is disturbing too).
There are also left-to-right as well as right-to-left composition operators in Control.Category, part of the base package. Compare >>> and <<< respectively:
ghci> :m + Control.Category
ghci> let f = (+2) ; g = (*3) in map ($1) [f >>> g, f <<< g]
[9,5]
There is a good reason to prefer left-to-right composition sometimes: evaluation order follows reading order.
jetxee
2010-05-26 14:41:47