Recently Don Syme made a post to the F# mailing list about some proposed changes to the F# libraries. In it talked about the virtues of using the new |> operator, sighting the following example as something it would be difficult without it:<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” />/o:p


let methods = System.AppDomain.CurrentDomain.GetAssemblies()/o:p

            |> List.of_array |> ( fun assm -> assm.GetTypes() ) |> Array.concat/o:p

            |> List.of_array |> ( fun t -> t.GetMethods() ) |> Array.concat/o:p


After squinting at it for a while I realised that I didn’t really understand what the sample was doing, let alone see the advantage of what the |> operator was doing. So I decided to try and rewrite it a number of different ways to see what was going on. First I tried the following:/o:p


let methods = Array.concat ( ( fun (t : System.Type) -> t.GetMethods() ) (List.of_array ( /o:p

            Array.concat( ( fun (assm : System.Reflection.Assembly) -> assm.GetTypes() ) /o:p

            (List.of_array (System.AppDomain.CurrentDomain.GetAssemblies()))))))/o:p


This made what was going clearer to me, but it was more the process of rewriting it that cleared things up. I came to the conclusion that I naturally start reading F# code at the bottom right and work backwards and this is a habit I need to get out of when looking at the |> operator. The reworked function doesn’t look that great because the lambdas need type annotations because F#’s type inference works from left to right so the type of lambda can not be inferred as they need to be inferred from something that appears on the right. And, probably worse, the function needs lots and lots of parenthesis to sort out the precedence of all the different functions being applied. /o:p


I made another rewrite using lots of intermediates:/o:p


let methods = let assmsArray = System.AppDomain.CurrentDomain.GetAssemblies() in/o:p

            let assemsList = List.of_array assmsArray in/o:p

            let typesArrayList = (fun (assm : System.Reflection.Assembly) -> assm.GetTypes() ) assemsList in/o:p

            let typesArray =  Array.concat ( typesArrayList ) in/o:p

            let typesList = List.ofarray( typesArray ) in/o:p

            let methodsArrayList = ( fun (t : System.Type) -> t.GetMethods() ) typesList in/o:p

            Array.concat methodsArrayList/o:p


This method is perhaps a little more clear but is almost twice as log as the original and still requires all the type annotations.  /o:p


The |> operator also has implications for Linq. I made an earlier post complaining that when using Linq either type annotations are necessary on the lambda or the lambdas get moved away from the function they work with. The |> operator can be used to sort this out. I rewrote my sample from that post using the |> operator and it looks a lot better:/o:p


let namesByFunction = (type string).GetMethods() /o:p

            |> where (fun m -> not m.IsStatic) |> groupBy (fun m -> m.Name ) /o:p

            |> select (fun m -> m.Key, count m.Group) |> orderBy (fun (, m) -> m)/o:p


The |> operator offers some nice advantages including reducing the need for type annotations when working with .NET types and help sort out function precedence. Perhaps more importantly it means functions can be written in the order that things will happen with out having to use lots of intermediates to hold results. After starting off as a bit of a cynic about the |> this little exercise has convinced me of its usefulness and I shall certainly be looking for places that the |> operator will be useful in my future F# programming./o:p


Feedback was imported from my only blog engine, it’s no longer possible to post feedback here.

re: Forwards is the new backwards with the |> operator - Don Syme

This post is really nice. I’ve linked a link on my blog entry on LINQ, linked above.