Introduction

I have been insanely driven by curiosity, maybe too long than necessary, to find the quintessential metaphysical thread that seamlessly connects all the functional programming concepts. Yes, this post is about composing software through functional programming (abbreviated here as FP) lens/perspective.

Lazy Vs Eager Evaluation

Coming from a solid experience that’s mostly rooted around OOPS/Procedural languages like C/C++/C#/JAVA, I was unaware of the functional lazy evaluation until Javascript. What is a lazy evaluation strategy?

 In layman’s terms, it’s about the delayed execution of a function or expression.

Let me explain in contrast with an eager evaluation with an example.

pseudocode of ADD method definition:

function add (a,b){

  print(‘evaluate adding numbers’);

 return a+b;

}

pseudocode of MULTIPLY method definition:

function multiply (c,d) {

print(‘evaluate multiplying number’);

  /* here for Lazy Evaluation, c is a function expression which gets lazily    */         

  /* evaluated at the point of  execution, hence the reversal of print statements */

return c*d;

}

Lazy Evaluation:

     mutiply( add(1,2), 3);

     Output: 

  1. evaluate multiplying number

  2. evaluate adding numbers

Eager Evaluation:

    mutiply( add(1,2), 3);

  Output: 

  1. evaluate adding numbers

  2. evaluate multiplying number

Lambdas Vs Function Pointers Vs Closures:
I have previously blogged about the mainstream OOPS programming languages (C#/JAVA) beefing its arsenal with FP concepts. Until Lambdas found their way into mainstream OOPS, all we had was function pointers or delegates in C#, to pass and return functions as parameters. But, they are unlike the closures in functional programming languages(pure FP Haskell or impure FP Javascript). Closures and Lambdas(anonymous functions) are more expressive, meaning that, they capture or close the parameters declared outside the function during execution time, unlike function pointer (in C) which is restricted (bounded by passed in data) to its passed in parameters. 

Curry Through Higher Order Haskell Function

   Pure FP Haskell is quite oddly interesting because it’s entirely in and out a Lazy Language. My friend David quite fondly calls the Madras Curry made in our home, a pot of liquid gold. Leaving aside the metaphorical pun, Haskell’s Curry (an FP concept) [1] [2] is inherently and literally a golden concept. Haskell functions can take functions as parameters and return functions as return values. A function that does either of these things is called a higher-order function.

Currying means— f (a,b,c) is equivalent to f (a)(b)(c)

Now let’s see how this weird function syntax works. If I successfully convey this idea, I will have passed my scientific/technical writing exam! Let’s see how this fairs out. 

f(a) {

       return f(b) {

                         return f(c) {

                                           return a+b+c;

                                      }

                   }

}

You see how each level returns the same function but takes one parameter at any given time, rather than f(a,b,c) which is the equivalent of the above elaborate syntax colored in red/blue/green. f(a) in red returns a function that has been partially applied with ‘a’ parameter. It’s like f(a) returns a function functionAppliedWithAValue(which is f actually, given a different variable name), then f(b) in blue returns functionAppliedWithAandBValue and then f(c) in green returns a functionAppliedWithAandBandC. And this is precisely why you do f(a)(b)(c). 

It goes like this, 

Variable functionAppliedWithAValue = f(a); /* remember f(a) return a raw function which is not yet executed */

Variable functionAppliedWithAandBValue = functionAppliedWithAValue(b);

Variable functionAppliedWithAandBandC = functionAppliedWithAandBValue(c);

I initially thought of Haskell syntax, but it will be a bit overwhelming to understand the syntax and then understand the curry concept. Hope I have made my point. 

Composing Software

Composing software (like building blocks) has been the core idea behind all languages. The coarser body of the unit in OOPS is an object and on the same tone, functions are the basic coarser unit in FP. LodashJS and RamdaJS are two libraries that have leveraged the curry and implemented all their API methods with auto-currying features too. If you have time please go over it and enjoy the taste of Haskell’s curry or Madras curry, as it’s fondly called too! I have barely scratched the surface. We will be looking into more functional features down the line.