Understanding F# Workflows


Published on

Scott Theleman - Understanding F# Workflows

F# Workflows are a powerful and elegant tool for solving many real-world problems, though they can be rather daunting at first. We'll survey some ways in which Workflows in the standard F# libraries are used for common development tasks, then dig into detail on how they work. We'll then build a workflow that provides a validation framework that can be used for parsing or other tasks.

Scott Theleman is a Software Developer with over 10 years professional design and development experience in both small startup and mid-sized corporate/Enterprise environments on applications ranging from desktop GUIs to website/web applications to server side and middleware work. He has also been Technical Lead on several government contracts.

He has worked on a diverse range of projects including a network discovery and topology product, a Learning Management System, Enterprise Service Oriented Architecture components for a large and complex search service, and atmospheric and weather sciences applications.

Language experience includes C++, Perl, Java and C#. He is currently working as a consultant on various projects including an atmospheric sciences product which will make extensive use of the latest Microsoft technologies including F# and WPF.

Published in: Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Understanding F# Workflows

  1. 1. Understanding F# Workflows<br />New England F# User’s Group Presentation (fsug.org)<br />August 2, 2010<br />Scott Theleman<br />
  2. 2. Overview<br />F# Workflows – closely related to Monads in Haskell and other languages – are a powerful and elegant tool for solving many real-world problems, though they can be rather daunting at first.<br />We'll survey some ways in which Workflows in the standard F# libraries are used for common development tasks, then dig into detail on how they work.<br />Finally we’ll build a workflow that provides a validation framework that can be used for parsing or other tasks.<br />
  3. 3. Intro to Monads<br />A “Monad” is generally a set of interrelated constructs. At the least, it usually consists of:<br />A “Monadic Type”<br />A bind function (sometimes the (>>=) operator is used)<br />A return function<br />“When the designers of F# talked with the designers of Haskell about this, they agreed that the word monad is obscure and sounds a little daunting and that using other names might be wise”<br />— Expert F# 2.0 (Don Syme, Adam Granicz, Antonio Cisternino)<br />
  4. 4. Characteristics of Monads<br />The Monadic Type “wraps” an underlying type. The monadic type may be more like an object (which may contain other data or state), or more like a computation or potential computation.<br />The Return function wraps an underlying type in a monadic type.<br />The Bind function takes an underlying type as well as a function which maps from the underlying type to a new monadic type, and returns a new monadic type.<br />By performing this wrapping of underlying types inside a monadic type and providing bind and return, you can now combine computations of that inner type in ways that are difficult or impossible when just dealing with the underlying types.<br />
  5. 5. Monad Structure<br />
  6. 6. Uses of Monads aka Workflows<br />
  7. 7. One use of Monads: Sequential Workflows<br />As noted, there are many uses and varieties of Monads<br />We will concentrate on solving a typical sequential workflow style problem<br />First showing other ways this has been done without workflows, then building up to using an F# workflow<br />
  8. 8. Sequential Workflows: If/else<br />The following code takes an initial input (of type T) and performs 3 sets of transformations on it, each time returning a tuple of bool and Result object (of type T). If there is a failure at any step, the entire operation is short circuited.<br />let process1 = true, input // do something with input<br />let process2 = false, input<br />let process3 = true, input<br /> <br />let Execute (input : 'T) =<br /> let ok, result1 = process1 input<br /> if ok then<br /> let ok, result2 = process2 result1<br /> if ok then<br /> let ok, result3 = process3 result2<br /> ok, result3<br /> else false, result2<br /> else false, result1<br />
  9. 9. If/else: Problems<br />The processX() methods and their callers all must know about the input and result types. Generics help the situation, but still these methods are hard-wired for those specific types, plus the success/failure Boolean.<br />Also, the 'T in Execute() and processX() is always the same!<br />It’s getting pretty messy, and we’ve only done 3 transformations. Pretty soon the code is going to be off the right side of the screen!<br />We have to explicitly handle failure at every step of the process<br />Lots of redundancy. We said “ok” 6 times!<br />We don’t have any information about what went wrong. Though we could define some sort of error type (see next example…).<br />
  10. 10. Sequential Workflows: Option and match<br />The following code tries to improve on the last sample. It now includes a Result<'T> type which we could expand upon to return detailed error information. It also uses pattern matching, which makes the code a bit clearer.<br />type Result<'T> = | Success of 'T | Failure of string<br /> <br />let process1 input = Success(input) // do something interesting here<br />let process2 input = Failure("Some error")<br />let process3 input = Success(input)<br />  <br />let Process (input : 'T) =<br /> let res1 = process1 input<br /> match res1 with<br /> | Failure _ -><br /> res1<br /> | Success v -><br /> let res2 = process2 v<br /> match res2 with<br /> | Failure _ -><br /> res2<br /> | Success v -><br /> let res3 = process3 v<br /> res3<br />
  11. 11. Option/match: Problems<br />Better than if/else, but…<br />Still messy and redundant and again the code is drifting off the right side of the screen<br />The processX() methods and their callers still must all know about the input and result types. The 'T in Execute() and processX() is still always the same<br />We still have to explicitly handle failure at every step of the process<br />The Result<'T>type does seem like a nice idea<br />
  12. 12. Sequential Workflows: try/catch<br />Try/catch could simplify/aggregate and improve things a bit – though just for this particular case. It does look nice and streamlined, which is one thing we are looking for.<br />exception MyProcessException of string<br /> <br />let process1 input = input<br />let process2 input = raise <| MyProcessException("An error occurred“)<br />let process3 input = input<br /> <br />// processX now accept and return T<br />// No Result any more; exceptions are used instead<br />let Execute (input : 'T) =<br /> try<br /> let v1 = process1 input<br /> let v2 = process2 v1<br /> let v3 = process3 v2<br /> v3<br /> with<br /> | :? MyProcessException as ex -><br /> // Catch application-specific error...do we throw or return a Result??<br />reraise ()<br /> | exn -><br /> // A "real" exception...what to do here?<br />reraise ()<br /> <br />let Caller<'T> v =<br /> // This will throw underlying exception on failure<br /> // Caller's caller will also have to handle it<br /> Execute v<br />
  13. 13. try/catch: Problems<br />Getting better, but…<br />Now we’re using the try/catch exception mechanism for handling short-circuiting errors rather than real exception cases. Is the exception just due to a typical error in processing or is it a “real” exception?<br />What does the caller do in this case? Note also that it becomes difficult for the caller to now be part of a larger workflow, or else a lot of hard-coded wireup<br />The “inner workflows” called by the top-level workflow all need to have try/catch and also throw the same Exception type (e.g. MyProcessException).<br />
  14. 14. Sequential Workflows: Extension Methods<br />Using Extension Methods to “chain” or “pipeline” (in a C#/Java kind of way).<br />The output of one function feeds the input of the next. Then, we wrap the whole thing in a try/catch.<br />exception MyException of stringtype WrapperObject(v : 'T) =    let value = v    member x.Value with get() = vmodule WrapperObjectExtensions =    type WrapperObject with        member x.Process1() = let v = x.Value + " Process1" in WrapperObject(v)        member x.Process2() = let v = x.Value + " Process2" in WrapperObject(v)         member x.Process3() = let v = x.Value + " Process3" in WrapperObject(v) open WrapperObjectExtensionslet Execute (input : string) =    let wrapper = WrapperObject(input)    try        let res =  wrapper.Process1().Process2().Process3()        res.Value    with    | :? MyException as ex ->        // throw or return a Result?        reraise ()    | exn ->        // A "real" exception        // What to do here?        reraise ()<br />
  15. 15. Sequential Workflows: Chained Objects<br />Using Interfaces, we return instances of object, on which further Process() can be called.<br />module ChainableObjectsWorkflowexception MyException of stringtype IChainableObject<'T> =    abstract Value : unit -> 'T with get    abstract Process : ('T -> 'T) -> IChainableObject<'T>type ChainableObject<'T>(v : 'T) as this =    let value = v    interface IChainableObject<'T> with        member x.Value with get() = value        override x.Process (f : ('T -> 'T)) =            let v = (this :> IChainableObject<_>).Value            let res = f v            ChainableObject(res) :> IChainableObject<'T>let process1 (s : string) = s + " Process1 applied"let process2 (s : string) = raise <| MyException("Error")let process3 (s : string) = s + " Process3 applied"<br />
  16. 16. Sequential Workflows: Chained Objects (continued)<br />Execute() function<br />let Execute (input : string) =    let co = ChainableObject(input) :> IChainableObject<_>    try        let res = co.Process(process1).Process(process2).Process(process3)        res.Value    with    | :? MyException as ex ->        // throw or return a Result?        reraise ()    | exn ->        // A "real" exception        // What to do here?        reraise ()<br />
  17. 17. Sequential Workflows: Pipelining<br />Similar to Extension Methods but with more idiomatic F# syntax with (|>) instead of dot syntax<br />exception MyException of string<br /> <br />let process1 input = input<br />let process2 input = raise <| MyException("An error occurred")<br />let process3 input = input<br /> <br />let Execute (input : 'T) =<br /> try<br /> input<br /> |> process1<br /> |> process2<br /> |> process3<br /> with<br /> | :? MyException as ex -><br /> // throw or return a Result?<br />reraise ()<br /> | exn -><br /> // A "real" exception<br /> // What to do here?<br />reraise ()<br />
  18. 18. Chaining, Pipelining, etc.: Problems<br />Getting better, but…<br />Still using the try/catch exception mechanism for handling short-circuiting errors rather than real exception cases.<br />We just get the result of the overall computation, but not each individual piece. What if the workflow wants to perform additional processing on pieces?<br />Once again, the 'T in Execute() and processX() is always the same<br />
  19. 19. Help from Continuations<br />module Continuationstype Result<'T> = | Success of 'T | Failure of stringlet process1 = (fun v -> Success("Process 1: " + v))let process2 = (fun v -> Failure("Process 2: An error occurred"))let process3 = (fun v -> Success("Process 3: " + v))<br />// Run f on v. If is succeeds, then call cont on that result, else return Failure<br />// Note that cont can transform the result into another typelet executeCont v (f : 'a -> Result<'a>) (cont : 'a -> Result<'b>) : Result<'b> = let maybe = f v<br /> match maybe with<br /> | Failure(err) -> Failure(err)<br /> | Success(result) -> cont result<br />let Execute v : Result<_> =    executeCont v process1 (fun result1 ->        executeCont result1 process2 (fun result2 ->            executeCont result2 process3 (fun result3 -> Success(result3))))<br />
  20. 20. Continuations<br />Now we’re getting somewhere!<br />Conditional computation – executeCont() can short-circuit<br />We have access to intermediate results and could use these at any future point in the workflow<br />The continuation function can transform the type from 'a to 'b. Now the types can be transformed in each stage of the workflow. More generic workflow helper functions (processX()) can be built which can manipulate different types.<br />Still, ugly syntax. Could we improve on this?<br />
  21. 21. A Better Way: F# Workflows<br />First define a “Result” type which can be Success or Failure, plus some additional info<br />Then define the “Monadic” type which wraps a type 'T into a function, which could be conditionally executed to return a Result<br />Note that Attempt<'T> is basically a continuation. The Workflow Builder we create next contains the logic to run the continuation (the entire rest of the workflow) after running the current step, or else not run additional Attempts if there is a failure, and simply return out of the entire workflow<br />type Error = { Message : string }/// A result/// If success, it contains some object, plus a message (perhaps a logging message)/// If failure, it returns an Error object (which could be expanded to be much richer)type Result<'T> =| Success of 'T * string| Failure of Errortype Attempt<'T> = (unit -> Result<'T>)<br />
  22. 22. F# Workflow Builder: Helper functions<br />let succeed (x,msg) = (fun () -> Success(x, msg)) : Attempt<'T>let fail err        = (fun () -> Failure(err)) : Attempt<'T>let failmsg msg     = (fun () -> Failure({ Message = msg })) : Attempt<'T>let runAttempt (a : Attempt<'T>) = a()let bind (f : Attempt<'T>) (rest : 'T -> Attempt<'U>) : Attempt<'U> =    match runAttempt f with    | Failure(msg)           -> fail msg    | Success(res, msg) as v -> rest reslet delay f = (fun () -> runAttempt (f()))let getValue (res:Result<'T>) = match res with    | Success(v,s) -> v    | Failure _ -> failwith "Invalid operation"<br />
  23. 23. F# Workflow Builder: The Workflow Builder Object<br />Uses the helper functions we just defined to create a “builder” class required by F#<br />Creates “processor” which is an instance of the builder. This is used to wrap all of these workflows using processor { } notation<br />Another “static class”, Processor, contains additional helper methods (kind of like the Async class)<br />type ProcessBuilder() =    member this.Return(x) = succeed x    member this.ReturnFrom(x) = x    member this.Bind(p, rest) = bind p rest    member this.Delay(f) = delay f    member this.Let(p, rest) : Attempt<'T> = rest ptype Processor() =    static member Run workflow =        runAttempt workflow        let processor = new ProcessBuilder()<br />
  24. 24. Mapping of Workflow Constructs<br />
  25. 25. F# Workflow: Final Result<br />See code for full example<br />type Customer =<br /> { Name : string; Birthdate : DateTime;  CreditScore : int; HasCriminalRecord : bool }let customerWorkflow c = processor {    let! ageTicket = processCustomer1 c    let! creditTicket = processCustomer2 c    let! criminalTicket = processCustomer3 c    // Process lots more stuff here...note how we can access result of each step    // If we didn't get to this point, then the entire workflow would have    // returned Result.Failure with the error message where the workflow failed    // If we got here, then all OK, assemble results and return    return ((c, [| ageTicket; creditTicket; criminalTicket |]), "Customer passed all checks!")    }/// If this succeeds, it returns a Result<Customer,int[]>/// else it returns a Failure with an error messagelet results = Processor.Run (customerWorkflow customer)<br />
  26. 26. F# Workflows: Bind De-Sugared<br />See code for full example<br />let customer =<br /> { Name = "Jane Doe";<br />DateTime.Parse("1/1/1960"); CreditScore = 640; HasCriminalRecord = false }let customerWorkflow c logger = processor {    let! ageResult  = processCustomer1 (c, logger)    let! creditResult  = processCustomer2 (c, logger)     let! criminalResult = processCustomer3 (c, logger)<br /> let ageTicket = getValue(ageResult)    let creditTicket  = getValue(creditResult)    let criminalTicket  = getValue(criminalResult)    return ((c, [| ageTicket; creditTicket; criminalTicket |]),<br /> "Customer passed all checks!", logger) }<br />// De-sugars to:<br />let finalResult = <br />processor.Bind(processCustomer1 c, (fun ageResult -><br />processor.Bind(processCustomer2 c, (fun creditResult -><br />processor.Bind(processCustomer3 c, (fun criminalResult -><br />processor.Let(getValue(ageResult), (fun ageTicket -><br />processor.Let(getValue(creditTicket), (fun creditTicket -><br />processor.Let(getValue(criminalResult), (fun criminalTicket -><br />processor.Return (c, [|ageTicket;creditTicket;criminalTicket|], logger<br /> ))))))))))<br />
  27. 27. ParseWorkflow Example<br />See example in code<br />Complete example which parses and validates a fixed-width format specification and returns Line, Position and Message on any errors<br />
  28. 28. Questions<br />Questions?<br />Thank you!<br />
  29. 29. References<br />Expert F# 2.0 (Don Syme, et al)<br />Real World Functional Programming (Tomas Petricek with Jon Skeet) at http://www.manning.com/petricek/<br />Lots of F# and Haskell references<br />Chance Coble “Why use Computation Workflows (aka Monads) in F#?” at http://leibnizdream.wordpress.com/2008/10/21/why-use-computation-workflows-aka-monads-in-f/<br />F# Survival Guide: Workflows at: http://www.ctocorner.com/fsharp/book/ch16.aspx<br />DevHawk series: http://devhawk.net/CategoryView,category,Monads.aspx<br />Understanding Haskell Monads (ErtugrulSöylemez) at http://ertes.de/articles/monads.html<br />Monads are like Burritos: http://blog.plover.com/prog/burritos.html (and others)<br />Many more<br />