Functional In Imperative

I respect the ideas of functional programming, and I have an interest in finding how modern imperative languages can take advantage of functional style.

I'm also interested in AntiCreation (not requiring to create every object), and functional languages do offer these benefits. As does the stack, shown below in some demos.

Why bother trying functional programming in an imperative language:

• for the sake of proving that functional coding style leads to harder to read code ;-)
• for finding out ways to produce less side effects in imperative code
• to bust some myths that higher order function and functional ideas cannot be used in some languages
• academic MentalMasturbation
• creativity stems from hacking around with ideas
• a different perspective
• cleverly finding ways to make stack objects or stack records play a role in faking functional programming (no heap required in some languages)

To many people's surprise, functional ideas and functional programming can be utilized in certain imperative languages (without using objects, too, as required in Java at times).

Can we use the ideas of higher order functions, and other functional tactics in imperative languages? Sure.

This page will show patterns of functional abilities in imperative oriented languages.

One example in freepascal:

This example prints 100: (7+3)×(7+3)

  program example; 

  type 
     int = integer;
     TIntFunc = function(x: int): int;

  function f(x: int): int; begin result:= x + 3; end;

  function g(func: TIntFunc; x: int): int; 
  begin 
    result:= func(x)*func(x); 
  end;

  begin
    writeln(g(@f, 7)); // prints 100
  end.

Another example in freepascal:

  program example; 

  type int = integer;
       Txy = record x, y: int; end;
       Tf = function(xy: Txy): int;

  function f(xy: Txy): int; begin result:= xy.y + xy.x; end;
  function g(func: Tf): Tf; begin result:= func; end;

  var a: Tf;
      xy: Txy = (x: 3; y: 7);
  begin  
    a:= g(@f);      // returns a function into "a"
    writeln(a(xy)); // prints 10
  end.

Another example using a stack based object:

  program example; 

  type int = integer;
       TFunc = object // stack object acts like higher order function
         x, y: int;
         function f: int;
       end;

  function TFunc.f: int; begin result:= y + x; end;
  function g(func: TFunc): TFunc; begin result:= func; end;

  var a: TFunc;
      param: TFunc;
  begin  
    a.x:= 3; a.y:= 7;  // like function parameters
    a:= g(a);  // return higher order function stack object
    writeln(a.f);  // prints 10
  end.

Examples in QompLanguage:

  t TIntFunc = fun(x: int): int;

  fun f(x: int): int; b res = x + 3; e;
  fun g(func: TIntFunc; x: int): int; b res = func(x)*func(x); e;

  b
    outln(g(@f, 7)); // prints 100
  e.

Another Qomp example:

  t Txy = rec x, y: int; e;
    Tf = fun(xy: Txy): int;

  fun f(xy: Txy): int; b res = xy.y + xy.x; e;
  fun g(func: Tf): Tf; b res = func; e;

  v a: Tf;
    xy: Txy = (x: 3; y: 7);
  b a = g(@f);    // returns a function into "a"
    outln(a(xy)); // prints 10
  e.

Stack based object Qomp example:

  t TFunc = object // stack object acts like higher order function
     x, y: int;
     fun f: int;
   e;

  fun TFunc.f: int; b res = y + x; e;
  fun g(func: TFunc): TFunc; b res = func; e;

  v a: TFunc;
  b a.x = 3; a.y = 7;  // acting like function parameters
    a = g(a);  // return higher order function stack object
    outln(a.f);  // prints 10
  e.

---

As you can see we can treat an object as if it were a higher order function, especially if it is stack based and so that it does not require verbose create and free clutter. Or, we don't have to use objects - as demonstrated with the other examples - especially if the language doesn't force us to use ugly pointers (as in Cee/C++) to emulate functional programming. So if the language allows our functions to accept functions as parameters and return functions as results (as in above) it makes coding functionally much easier.

Still, all this functional function functionalism talk confuses the average person - and is one reason functional programming isn't popular.

I also find functional style harder to read, no matter what language is being used (even pure functional languages) - since the human brain has to focus on so many functions at once, and remember which functions are being passed in to which ones, returning which functions. Oogly boogly.. confusing even for the experienced programmer at times. I think, this is why functional programming isn't as popular as it could be - simply because it requires multi tasking your brain to grasp all the functions that relate to other functions taht return functions as functions functions (and this is why people have trouble with Lisp, methinks).

Another experiment I did, was reusing chunks of code in a functional kind of way while still making use of an imperative loop:

The above loop could be replaced using recursion to, so that there is no imperative loop.

At this point, though, I question where to draw the line - as the code seems to become more and more funny looking (funny as in functional). Once again, I think this is why functional programming is not as popular today - because people seem to be used to typical imperative code that reads out in a block like nature. I'd guess that 90 percent of imperative programming language users don't even know that they can make use of functional programming ideas and tactics within their imperative language.