Rash thoughts about .NET, C#, F# and Dynamics NAV.

"Every solution will only lead to new problems."

Sunday, 18. October 2009

xUnit.net support in “FAKE – F# Make” 0.14

Filed under: F#,FAKE - F# Make — Steffen Forkmann at 18:09 Uhr

Yesterday I released “FAKE – F# Make” version 0.14 with xUnit.net support. The usage is very easy and similar to the usage of NUnit:

Target "xUnitTest" (fun () -> 

  let testAssemblies =

    !+ (testDir + @"\Test.*.dll")

      |> Scan



    (fun p ->

       {p with

           ShadowCopy = false;

           HtmlPrefix = testDir})



This sample works perfectly with TeamCity and creates a html-page per test project in addition:

TeamCity output

HMTL output

If you want to publish the xUnit.net test results in CruiseControl.NET just modify the build script a little:

Target "xUnitTest" (fun () -> 

  let testAssemblies =

    !+ (testDir + @"\Test.*.dll")

      |> Scan



    (fun p ->

       {p with

           ShadowCopy = false;

           HtmlPrefix = testDir;

           XmlPrefix = testDir })



Now follow the steps in the CrusieControl.NET documentation. You will need to download the xUnitSummary.xsl file and save it to your webdashboard directory. If everything works correctly you should see something like this:

CruisControl.NET output

Tags: , , , , ,

Friday, 16. October 2009

My upcoming F# talks

Filed under: F# — Steffen Forkmann at 11:17 Uhr

Last week I talked about F# and functional programming at .NET User Group Paderborn. Here are the dates for my upcoming F# talks:

Abstract (in german):

Funktionale Programmiersprachen nehmen seit geraumer Zeit einen hohen Stellenwert in der Wissenschaft ein. Demnächst könnte es eine dieser Sprachen sogar aus dem Forschungsbereich direkt in den Mainstream schaffen. Visual Studio 2010 wird neben C# und VB.NET die funktionale Programmiersprache F# als dritte Hauptsprache anbieten. Der Vortrag soll einen Einblick in funktionale Konzepte und deren Umsetzung in F# geben. Insbesondere soll auf “Funktionen höherer Ordnung”, Typinferenz, Currying, Pattern Matching, “Unveränderlichkeit” und parallele Programmierung eingegangen werden.

Tags: , , , ,

Wednesday, 14. October 2009

Integrating a “FAKE – F# Make” build script into CruiseControl.NET

Filed under: F#,FAKE - F# Make — Steffen Forkmann at 10:38 Uhr

Since version 0.12 the FAKE build system provides an easy way to setup build configurations for CruiseControl.NET.

“CruiseControl.NET is an Automated Continuous Integration server, implemented using the Microsoft .NET Framework.”


In this article I will show you how you can set up a FAKE build script in CruiseControl.NET. We will use the CalculatorSample which you can download from the FAKE Download page.

If you want to know how this build script works and how you could create one for your own projects please read the “Getting started with FAKE”-tutorial.

If you want to set up “FAKE – F# Make” build configurations in TeamCity please read “Integrating a "FAKE – F# Make" build script into TeamCity”.

Installing CruiseControl.NET

You can download CruiseControl.NET from thoughtworks.org. After the installation process (further instructions) you should see an empty dashboard:

CruiseControl.NET Dashboard

Installing Subversion

The CalculatorSample is using Subversion (SVN) for SourceControl, so we need to download SVN from subversion.tigris.org. I’m using the “Windows MSI installer with the basic win32 binaries” and installed them under “c:\Program Files (x86)\Subversion\”.

Installing FxCop

The CalculatorSample is using FxCop, so we need to download and install it next.

“FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements. Many of the issues concern violations of the programming and design rules set forth in the Design Guidelines for Class Library Developers, which are the Microsoft guidelines for writing robust and easily maintainable code by using the .NET Framework.”


Creating a FAKE Project

Now create a new folder for the CalculatorSample sources. I’m using “d:\Calculator\” for the rest of the article.

The next step is to modify the CruiseControl.NET config file (“c:\Program Files (x86)\CruiseControl.NET\server\ccnet.config” on my machine):





       <intervalTrigger name="continuous" seconds="30" initialSeconds="30"/>


    <sourcecontrol type="svn">

      <executable>c:\Program Files (x86)\Subversion\bin\svn.exe</executable>



















      <xmllogger />




In this configuration I set up a trigger which checks every 30 sec. for changes in my CalculatorSample project.

If SVN finds changes FAKE.exe is called with my build script (completeBuild.fsx).

After the build I want to merge the FxCop and NUnit output files with my build results to create a build report.

Configuring the dashboard

In order to provide a nicer output on the dashboard we need to modify the BuildPlugins section in the dashboard.config file (“c:\Program Files (x86)\CruiseControl.NET\webdashboard\dashboard.config” on my machine):












  <buildLogBuildPlugin />


     description="NCover Report"



  <xslReportBuildPlugin description="FxCop Report"


     xslFileName="xsl\fxcop-report_1_36.xsl" />

  <xslReportBuildPlugin description="NUnit Report"


     xslFileName="xsl\tests.xsl" />


As you can see we use the nant.xsl to transform the FAKE output to HTML.

Starting the build

Now if everything is configured correctly, you can tell CruiseControl.NET to run your build (press “Start” for your build project on the dashboard):

Press Start on the dashboard

Now CruiseControl.NET should use SVN to checkout the CalculatorSample sources and run the build. The output on the project page for build 1 should look like this:

Build output

Build output 2

You can also inspect the NUnit and FxCop results:

 NUnit zest results

FxCop results

Please feel free to give feedback if you have any problems with this article.

Tags: , , , , , ,

Tuesday, 13. October 2009

Redirecting process output in F#

Filed under: F# — Steffen Forkmann at 16:03 Uhr

Today I had some trouble to redirect the default and error output from a created process. So here is my final solution:

  open System.Diagnostics

  open System.Threading


  // outputF: string -> unit

  // errorF: string -> unit

  let runProcess outputF errorF =

    use p = new Process()

    p.StartInfo.UseShellExecute <- false

    // …

    p.StartInfo.RedirectStandardOutput <- true

    p.StartInfo.RedirectStandardError <- true



      (fun d –> if  d.Data <> null then errorF d.Data)


      (fun d –> if d.Data <> null then outputF d.Data)

    p.Start() |> ignore








Tags: ,

Tuesday, 6. October 2009

“FAKE – F# Make” Version 0.10 released

Filed under: F#,FAKE - F# Make — Steffen Forkmann at 11:59 Uhr

I just released a new version of my Open Source Build Automation Framework “FAKE – F# Make”. You can read more about FAKE on the project website or in the Getting started with "FAKE – F# Make"-article.

Although the new release contains many bugfixes, I only want to show the two major improvements here.

1. FAKE 0.10 uses FSI instead of FSC

From now on FAKE uses the “F# Interactive” (fsi.exe) instead of the F# Compiler (fsc.exe) to run the build scripts, which brings two major improvements.

No TempPath for compiled binaries needed

Due to the fact that FAKE scripts are no longer compiled at the beginning of the build process, we don’t need a temporary folder for the created binaries.

Loading modules at runtime

The #load command in F# scripts allows us to load modules at runtime. Now we are able to put reusable Targets or TargetTemplates (see below) into external build script files.

2. TargetTemplates

TargetTemplates provide an easy way to reuse common Targets. Let’s consider a (very) small sample:

Target "TraceHello" (fun () ->

  trace "Hello World from FAKE"


This Target “TraceHello” traces a “Hello World” string into our build log. Now we want it to be slightly more generic and to trace a custom string. We can do this by using a TargetTemplate:

/// createTraceTarget: string -> string -> Target

let createTraceTarget = TargetTemplate (fun s ->

  trace s


Now we have a template (or a function which generates targets) that gets a string for the target name and a string for the trace text and generates  a usable target:

createTraceTarget "TraceHello" "Hello World from FAKE"

createTraceTarget "Trace2" "Trace another text"

Of course the TargetTemplate function is generic and can be used with any tuple as parameter:

/// createTraceTarget: string -> string*int -> Target

let createTraceTarget = TargetTemplate (fun (s,d) ->

  trace s

  trace <| sprintf "my int: %d" d



createTraceTarget "TraceHello" ("Hello World from FAKE",2)

createTraceTarget "Trace2" ("Trace another text",42)

Tags: , , ,

Monday, 24. August 2009

SOLID Part I – The Open/Closed-Principle – C# vs. F#

Filed under: C#,English posts,F#,Veranstaltungen — Steffen Forkmann at 11:43 Uhr

Friday I attended the .NET BootCamp “NHibernate vs. Entity Framework” in Leipzig and as always it was a pleasure for me being there. Afterwards I had a nice talk with my friend Alexander Groß about the Open/Closed Principle. I didn’t really care about this principle before, but now I think it’s really a nice idea:

“In object-oriented programming, the open/closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"; that is, such an entity can allow its behaviour to be modified without altering its source code.”


If we follow this principle we get lot’s of small and testable classes. I want to demonstrate this with a simple spam checker for mails.

Let’s say our mail class has only a sender, a recipient, a subject and the mail body:

public class EMail


    public string Sender { get; set; }

    public string Recipient { get; set; }

    public string Subject { get; set; }

    public string Body { get; set; }


    public EMail(string sender, string recipient,

        string subject, string body)


        Sender = sender;

        Recipient = recipient;

        Subject = subject;

        Body = body;




public enum SpamResult






Now we want to know if a mail is spam or not. Of course we need some rules and some kind of “rule checker” to decide this. Here is a very naïve implementation for this:

public class RuleChecker


    public SpamResult CheckMail(EMail mail)


        var result = TestRule1(mail);

        if(result != SpamResult.Unknown)

            return result;


        result = TestRule2(mail);

        if (result != SpamResult.Unknown)

        return result;


        // …

        return SpamResult.Unknown;



    private SpamResult TestRule1(EMail mail)


        // I don’t care about the concrete rules



    private SpamResult TestRule2(EMail mail)


        // I don’t care about the concrete rules



It is obvious that this implementation breaks the Open/Closed Principle. Every time someone comes up with a new anti-spam rule or the rule priorities change I have to modify the code in CheckMail(). Another problem here is that I can’t test CheckMail() isolated from the concrete rules.

With the help of the Open/Closed Principle our implementation could look like this:

public interface ISpamRule


    SpamResult CheckMail(EMail mail);



public class RuleChecker


    private readonly IEnumerable<ISpamRule> _rules;


    public RuleChecker(IEnumerable<ISpamRule> rules)


        _rules = rules;



    public SpamResult CheckMail(EMail mail)


        foreach (var rule in _rules)


            var result = rule.CheckMail(mail);

            if (result != SpamResult.Unknown)

                return result;


        return SpamResult.Unknown;



Now you could easily write isolated UnitTests for RuleChecker.CheckMail() and for every new rule.

You get the your concrete RuleChecker by calling the constructor with a list of rules:

class MyFirstRule : ISpamRule


    public SpamResult CheckMail(EMail mail)


        // I don’t care about this




class MySecondRule : ISpamRule


    public SpamResult CheckMail(EMail mail)


        // I don’t care about this



// …

var ruleChecker =

    new RuleChecker(

        new List<ISpamRule>


            new MyFirstRule(),

            new MySecondRule(),

            // …


Alex please correct me if I’m wrong, but I think this is what you had in mind Friday.

As stated before, we end up writing lot’s of very small classes – mostly with only one (public) method. I think this is some kind of functional approach, the only question is how we glue our code entities together. Let’s look at the corresponding F# implementation:

type EMail =

  { Sender: string;

    Recipient: string;

    Subject: string;

    Body: string}


type SpamResult =

  | Spam

  | OK

  | Unknown


let checkMail rules (mail:EMail) =

  let rec checkRule rules =

    match rules with

    | rule::rest ->

      match rule mail with

      | Unknown -> checkRule rest

      | _ as other -> other

    | [] –> Unknown


  checkRule rules

The signature of checkMail is (EMail -> SpamResult) list -> EMail –> SpamResult, which means it takes a list of rules (as above the order is important) and a EMail and returns the SpamResult. In addition I exchanged the explicit foreach loop with a tail recursion to make it look more functional.

If I want a concrete rule checker I could use partial application:

let myFirstRule mail =

  // I don’t care about this

let mySecondRule mail =

  // I don’t care about this

// val ruleChecker :  (EMail –> SpamResult)

let ruleChecker =


    [ myFirstRule;


As you can see the F# implementation is nearly the same as the C# implementation, just without explicitly wrapping our public method in classes. If we would use Reflector we would see that the F# compiler is building the classes around our functions. One could say if we follow the Open/Closed Principle we come to functional code or the other way around if we write functional code we automatically apply the Open/Closed Principle. I think that’s why I really didn’t care about this before.


After thinking about this implementation and the extra type hint (see mail:EMail) I came up with a slightly more generic implementation:

type SpamResult =

  | Spam

  | OK


let checkRules rules element =

  let rec checkRule rules =

    match rules with

    | rule::rest ->

      match rule element with

      | None -> checkRule rest

      | _ as other -> other

    | [] –> None


  checkRule rules

Here I deleted the enum value for SpamResult.Unknown and used the standard None option. As a consequence the signature changed to:  val checkRules : (‘a -> ‘b option) list -> ‘a -> ‘b option. The function still takes a list of rules and a element and returns a option value. Now the checkRules function works with every kind of rule result and takes arbitrary elements.

Tags: , , , ,

Thursday, 2. July 2009

F# BootCamp – Questions and Answers – part IV – Structural comparison

Filed under: English posts,F# — Steffen Forkmann at 17:37 Uhr

This is the third part in a “Questions and Answers”-series about the F# BootCamp in Leipzig. This time we will look at structural comparison and structural equality.

Question 6: Please describe the terms “Structural Comparison” and “Structural Equality”.

This was a simple question. Basically the answer is F# provides a default implementation for IComparable and .Equals() for all custom types. This default implementation compares all public fields of the two instances. Let’s consider some samples:

let a = 3,4,"foo"
let b = 3,4,"bar"

printfn "a > b = %b" (a > b) // true
printfn "a < b = %b" (a < b) // false
type MySimpleRecord =
  { a: int;
    b: int;}
type MyCompositeRecord =
  { x: string;
    y: int;
    z: MySimpleRecord}

let a =   
  { x = "Test";
    y = 3;
    z = {a = 1; b = 4;}}
let b = 
  { x = "Test";
    y = 3;
    z = {a = 1; b = 2;}}

// Structural comparison
printfn "a > b = %b" (a > b) // true
printfn "a < b = %b" (a < b) // false

printfn "Min(a,b) = %A" (min a b)
printfn "compare(a,b) = %d" (compare a b) 
let a = [3; 2; 4; 5]
let b = [3; 2; 4; 3; 3]

// Structural comparison
printfn "a > b = %b" (a > b) // true
printfn "a < b = %b" (a < b) // false

printfn "Min(a,b) = %A" (min a b)
printfn "compare(a,b) = %d" (compare a b)
Tags: , ,

Wednesday, 1. July 2009

Extensibility of functions with lambdas (in F# and C#)

Filed under: English posts,F# — Steffen Forkmann at 16:02 Uhr

One of the nice properties of functional programming languages is the easy extensibility of custom functions. Let’s consider a simple F# function (from “FAKE – F# Make”) for a recursive directory copy:

open System
open System.IO

/// Copies a directory recursive
/// Thanks to Robert Pickering http://strangelights.com/blog/
///  param target: target directory : string
///  param source: source directory : string
let CopyDir target source =
  Directory.GetFiles(source, "*.*", SearchOption.AllDirectories)
    |> Seq.iter (fun file -> 
      let newFile = target + file.Remove(0, source.Length)
      printf "%s => %s" file newFile
      Directory.CreateDirectory(Path.GetDirectoryName(newFile)) |> ignore
      File.Copy(file, newFile, true))

If we want to allow users to set custom file filters, we can add a third parameter:

/// Copies a directory recursive
/// and allows to filter the files
/// Thanks to Robert Pickering http://strangelights.com/blog/
///  param target: target directory : string
///  param source: source directory : string
///  param filterFile: FilterFunction: string -> bool
let CopyDirFiltered target source filterFile =
  Directory.GetFiles(source, "*.*", SearchOption.AllDirectories)
    |> Seq.filter filterFile
    |> Seq.iter (fun file -> 
      let newFile = target + file.Remove(0, source.Length)
      printfn "%s => %s" file newFile
      Directory.CreateDirectory(Path.GetDirectoryName(newFile)) |> ignore
      File.Copy(file, newFile, true))

Now we can define some filter functions:

/// Exclude SVN files (path with .svn)
/// excludeSVNFiles: string -> bool 
let excludeSVNFiles (path:string) = not <| path.Contains ".svn"

/// Includes all files
/// allFiles: string -> bool 
let allFiles (path:string) = true

Now it is possible to use CopyDirFiltered in the following ways:

/// Copies all files <=> same as CopyDir
CopyDirFiltered "C:\\target" "C:\\source" allFiles

/// Copies all files except SVN files
CopyDirFiltered "C:\\target" "C:\\source" excludeSVNFiles

/// Copies all files only if random number <> 2
let r = new Random()
CopyDirFiltered "C:\\target" "C:\\source" (fun path -> r.Next(5) <> 2)
Extensibility of functions in C#

Of course we can do the same thing in C# 3.0:

/// <summary>
/// Copies a directory recursive
/// and allows to filter the files
/// </summary>
/// <param name="target">The target.</param>
/// <param name="source">The source.</param>
/// <param name="fileFilter">The file filter.</param>
public static void CopyDirFiltered(string target, string source,
                                   Func<string, bool> fileFilter)
    string[] allFiles = Directory.GetFiles(
        source, "*.*", SearchOption.AllDirectories);
    foreach (string file in from f in allFiles
                            where fileFilter(f)
                            select f)
        string newFile = target + file.Remove(0, source.Length);
        Console.WriteLine("{0} => {1}", file, newFile);
        File.Copy(file, newFile, true);

Now it is easy to use the C# function with lambdas:

“A lambda expression is an anonymous function that can contain expressions and statements, and can be used to create delegates or expression tree types.”


Func<string, bool> filterSVN = x => !x.Contains(".svn");
Func<string, bool> allFiles = x => true;

/// Copies all files <=> same as CopyDir
CopyDirFiltered("C:\\target", "C:\\source", allFiles);

/// Copies all files except SVN files
CopyDirFiltered("C:\\target", "C:\\source", filterSVN);

/// Copies all files only if random number <> 2
var r = new Random();
CopyDirFiltered("C:\\target", "C:\\source", path => r.Next(5) != 2);

Keeping this simple technique in mind allows to create very flexible functions.

Tags: , , ,

Wednesday, 24. June 2009

F# BootCamp – Questions and Answers – part III – Lazy evaluation

Filed under: English posts,F#,Informatik — Steffen Forkmann at 11:27 Uhr

This is the third part in a “Questions and Answers”-series about the F# BootCamp in Leipzig. This time we will look at lazy evaluation.

Question 5 – What is the difference between “Lazy Evaluation” and “Eager evaluation”?

Lazy evaluation is a technique of delaying a computation until the result is required. If we use eager evaluation an expression is evaluated as soon as it gets bound to a variable.

One participant answered that lazy evaluation is used in most programming languages to calculate boolean expressions faster. For instance in the expression “x() or y()” the function y() is never called if x() returns true.

Of course this answer is correct, but this "short-circuit evaluation" is only a special case of lazy evaluation. The program would also work correctly without it. But if we want to define an infinite sequence then we can not use eager evaluation. Let’s look at an example:

// val fibs: seq<int>
let fibs = (1, 1) |> Seq.unfold(fun (n0, n1) -> Some(n0, (n1, n0 + n1)))

We do not need to understand the concrete syntax of this code here. We’ll discuss this later. Let’s just say fibs is bound to an infinite sequence (IEnumerable<int>) of Fibonacci numbers. You could also write this in C#:

/// <summary>
/// Infinite sequence of Fibonacci numbers.
/// </summary>
public static IEnumerable<int> Fibs()
    var n0 = 1;
    var n1 = 1;
        yield return n0;
        var t = n1;
        n1 = n1 + n0;
        n0 = t;

The trick is IEnumerable evaluates the elements lazy. Only at the time we take an element from the sequence the element will be computed:

  |> Seq.take 10
  |> Seq.to_list
  |> printfn "%A" // prints [1; 1; 2; 3; 5; 8; 13; 21; 34; 55]

If we would use eager evaluation then “Seq.take” would never been called. But we can go one step further. If we want to get the first 10 even-valued terms in the Fibonacci sequence, we can write this code:

  |> Seq.filter (fun fib -> fib % 2 = 0) // lazy (via pipe)
  |> Seq.take 10                         // lazy (via pipe)
  |> Seq.to_list                         // eager
  |> printfn "%A" 
// prints [2; 8; 34; 144; 610; 2584; 10946; 46368; 196418; 832040]

This would be a little bit tricky if we use eager evaluation, but of course this nice laziness comes with some costs for storing intermediate results (and code). So eager evaluation is still often the better choice and sometimes (e.g. DateTime.Now()) it makes no sense to use lazy evaluation – at least not if we don’t reevaluate the function.

Tags: , ,

Wednesday, 17. June 2009

F# BootCamp – Questions and Answers – part II – Currying

Filed under: C#,English posts,F#,FAKE - F# Make,Informatik,Mathematik,Veranstaltungen — Steffen Forkmann at 12:36 Uhr

Yesterday I was talking about F# at the .NET Developer Group Braunschweig. It was my first talk completely without PowerPoint (just Live-Coding and FlipChart) and I have to admit this is not that easy. But the event was really a big fun and we covered a lot of topics like FP fundamentals, concurrency and domain specific languages (of course I showed “FAKE – F# Make”).

Now I have a bit time before I go to the next BootCamp in Leipzig. Today Christian Weyer will show us exciting new stuff about WCF and Azure.

In the meanwhile I will write here about another important question (see first article) from the F# BootCamp in Leipzig:

Question 4 – Try to explain “Currying” and “Partial Application”. Hint: Please show a sample and use the pipe operator |>.

Obviously this was a tricky question for FP beginners. There are a lot of websites, which give a formal mathematical definition but don’t show the practical application.

“Currying … is the technique of transforming a function that takes multiple arguments (or more accurately an n-tuple as argument) in such a way that it can be called as a chain of functions each with a single argument”


I want to show how my pragmatic view of the terms here, so let’s consider this small C# function:

public int Add(int x, int y)
   return x + y;

Of course the corresponding F# version looks nearly the same:

let add(x,y) = x + y

But let’s look at the signature: val add : int * int –> int. The F# compiler is telling us add wants a tuple of ints and returns an int. We could rewrite the function with one blank to understand this better:

let add (x,y) = x + y

As you can see the add function actually needs only one argument – a tuple:

let t = (3,4)         // val t : int * int
printfn "%d" (add t)  // prints 7 – like add(3,4)

Now we want to curry this function. If you’d ask a mathematician this a complex operation, but from a pragmatic view it couldn’t be easier. Just remove the brackets and the comma – that’s all:

let add x y = x + y

Now the signature looks different: val add : int -> int –> int

But what’s the meaning of this new arrow? Basically we can say if we give one int parameter to our add function we will get a function back that will take only one int parameter and returns an int.

let increment = add 1      // val increment : (int -> int)
printfn "%d" (increment 2) // prints 3

Here “increment” is a new function that uses partial application of the curryied add function. This means we are fixing one of the parameters of add to get a new function with one parameter less.

But why are doing something like this? Wouldn’t it be enough to use the following increment function?

let add(x,y) = x + y       // val add : int * int -> int 
let increment x = add(x,1) // val increment : int -> int
printfn "%d" (increment 2) // prints 3

Of course we are getting (nearly) the same signature for increment. But the difference is that we can not use the forward pipe operator |> here. The pipe operator will help us to express things in the way we are thinking about it.

Let’s say we want to filter all even elements in a list, then calculate the sum and finally square this sum and print it to the console. The C# code would look like this:

var list = new List<int> {4,2,6,5,9,3,8,1,3,0};

If we don’t want to store intermediate results we have to write our algorithm in reverse order and with heavily use of brackets. The function we want to apply last has to be written first. This is not the way we think about it.

With the help of curried functions, partial application and the pipe operator we can write the same thing in F#:

let list = [4; 2; 6; 5; 9; 3; 8; 1; 3; 0]

let square x = x * x
 |> List.filter (fun x -> x % 2 = 0) // partial application
 |> List.sum
 |> square
 |> printfn "%A"                     // partial application

We describe the data flow in exactly the same order we talked about it. Basically the pipe operator take the result of a function and puts it as the last parameter into the next function.

What should we learn from this sample?

  1. Currying has nothing to do with spicy chicken.
  2. The |> operator makes life easier and code better to understand.
  3. If we want to use |> we need curryied functions.
  4. Defining curryied functions is easy – just remove brackets and comma.
  5. We don’t need the complete mathematical theory to use currying.
  6. Be careful with the order of the parameter in a curryied function. Don’t forget the pipe operator puts the parameter from the right hand side into your function – all other parameters have to be fixed with partial application.
Tags: , , , , , , , ,