# Partial Application A particularly convenient feature of F# is that complicated functions with many parameters can have some of the parameters fixed or "baked in" and yet leave other parameters open. In this post, we'll take a quick look at how this might be used in practice. Let's start with a very simple example of how this works. We'll start with a trivial function: ```fsharp // define a adding function let add x y = x + y // normal use let z = add 1 2 ``` But we can do something strange as well ? we can call the function with only one parameter! ```fsharp let add42 = add 42 ``` The result is a new function that has the "42" baked in, and now takes only one parameter instead of two! This technique is called "partial application", and it means that, for any function, you can "fix" some of the parameters and leave other ones open to be filled in later. ```fsharp // use the new function add42 2 add42 3 ``` With that under our belt, let's revisit the generic logger that we saw earlier: ```fsharp let genericLogger anyFunc input = printfn "input is %A" input //log the input let result = anyFunc input //evaluate the function printfn "result is %A" result //log the result result //return the result ``` Unfortunately, I have hard-coded the logging operations. Ideally, I'd like to make this more generic so that I can choose how logging is done. Of course, F# being a functional programming language, we will do this by passing functions around. In this case we would pass "before" and "after" callback functions to the library function, like this: ```fsharp let genericLogger before after anyFunc input = before input //callback for custom behavior let result = anyFunc input //evaluate the function after result //callback for custom behavior result //return the result ``` You can see that the logging function now has four parameters. The "before" and "after" actions are passed in as explicit parameters as well as the function and its input. To use this in practice, we just define the functions and pass them in to the library function along with the final int parameter: ```fsharp let add1 input = input + 1 // reuse case 1 genericLogger (fun x -> printf "before=%i. " x) // function to call before (fun x -> printfn " after=%i." x) // function to call after add1 // main function 2 // parameter // reuse case 2 genericLogger (fun x -> printf "started with=%i " x) // different callback (fun x -> printfn " ended with=%i" x) add1 // main function 2 // parameter ``` This is a lot more flexible. I don't have to create a new function every time I want to change the behavior -- I can define the behavior on the fly. But you might be thinking that this is a bit ugly. A library function might expose a number of callback functions and it would be inconvenient to have to pass the same functions in over and over. Luckily, we know the solution for this. We can use partial application to fix some of the parameters. So in this case, let's define a new function which fixes the `before` and `after` functions, as well as the `add1` function, but leaves the final parameter open. ```fsharp // define a reusable function with the "callback" functions fixed let add1WithConsoleLogging = genericLogger (fun x -> printf "input=%i. " x) (fun x -> printfn " result=%i" x) add1 // last parameter NOT defined here yet! ``` The new "wrapper" function is called with just an int now, so the code is much cleaner. As in the earlier example, it can be used anywhere the original `add1` function could be used without any changes. ```fsharp add1WithConsoleLogging 2 add1WithConsoleLogging 3 add1WithConsoleLogging 4 [1..5] |> List.map add1WithConsoleLogging ``` ## The functional approach in C# #\# In a classical object-oriented approach, we would probably have used inheritance to do this kind of thing. For instance, we might have had an abstract `LoggerBase` class, with virtual methods for "`before`" and "`after`" and the function to execute. And then to implement a particular kind of behavior, we would have created a new subclass and overridden the virtual methods as needed. But classical style inheritance is now becoming frowned upon in object-oriented design, and composition of objects is much preferred. And indeed, in "modern" C#, we would probably write the code in the same way as F#, either by using events or by passing functions in. Here's the F# code translated into C# (note that I had to specify the types for each Action) ```csharp public class GenericLoggerHelper { public TResult GenericLogger( Action before, Action after, Func aFunc, TInput input) { before(input); //callback for custom behavior var result = aFunc(input); //do the function after(result); //callback for custom behavior return result; } } ``` And here it is in use: ```csharp [NUnit.Framework.Test] public void TestGenericLogger() { var sut = new GenericLoggerHelper(); sut.GenericLogger( x => Console.Write("input={0}. ", x), x => Console.WriteLine(" result={0}", x), x => x + 1, 3); } ``` In C#, this style of programming is required when using the LINQ libraries, but many developers have not embraced it fully to make their own code more generic and adaptable. And it's not helped by the ugly `Action<>` and `Func<>` type declarations that are required. But it can certainly make the code much more reusable. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://swlaschin.gitbook.io/fsharpforfunandprofit/why-use-f/why-use-fsharp/convenience-partial-application.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.