Functional Programming – How to Organize Chain of Functions Sharing Parameters

design-patternsfunctional programmingprogramming practices

When trying to follow a functional programming paradigm, I often find myself in a situation where I have a chain of functions that I would want to combine/compose somehow, but they all also take in a similar set of parameters. I've been trying to research best practices surrounding this kind of set up, because it's not immediately obvious how to combine them, and I don't want to end up with some esoteric solution. I'm also open to the possibility that there may be ways to avoid this sort of problem entirely.

To be more concrete, I noticed the trend working on two unrelated projects: interacting with a peculiar API and an agent based simulation.

For the API, I needed to make multiple calls to get the information I needed. Each call needing some information from the last, and each call needed the same general information (like the url, various object ids, and some option parameters).
For the agent based simulation, in each iteration I needed to make a series of updates to the population of agents as they interacted and evolved through various stages. Each stage needed the state of the previous stage's update, and each stage needed the same general information (like parameters dictating how the agents interact and change, and how to create new agents, etc)

These aren't the only two examples, just the most recent, and usually in the past I end up giving up and going back to OOP. It sort of makes sense, because if I have a chain of functions all with the same first parameter, that's sort of like how all object methods in Python take self as the first argument. But I'm sure the functional paradigm has another way of tackling this.

Hopefully that makes the problem clear. In sum, what are standard ways to handle these "ambient" parameters in a functional context?

Some paths I've tried that may further clarify the issue

One potential solution I thought about was a sort of composition "lift". For example, if I have two function f :: X -> (A -> B) and g :: X -> (B -> C), I could compose them into a function of type X -> (A -> C) with an implementation like lift_compose f g x = (f x) . (g x). However, I don't have the aesthetic knowledge to know if this is considered "clean", or the vocabulary to know if this is already called something standard.

It also becomes a problem for longer chains of functions functions, like if h :: X -> (C -> D) actually also needs a little information from what type A was in f. In that case the composition isn't as straightforward. Something I tried was having a series of data types that inherited fields from each other, and each function essentially added a field to the data and passed it on. For example:

type A:
    ambient_info : str
    more_info : str

type B (inherits from A)
   new_info : str

type C (inherits from B)
   newer_info : str

Then I could make the functions just f :: A -> B and g :: B -> C and so on for however many steps, and compose normally, keeping all the information throughout. However, this started to feel strange and non standard. Again, this is pretty hard to search because I just don't have the right words. Thanks for any help.

Also, I wrote these examples in a weird pseudo Haskell, but I'm looking for something as language agnostic as practical, since I don't actually get to work in Haskell very much. Python is my main fluency, but I see this as generally affecting me whatever language I'm writing in.

Best Answer

One alternative is, in case these "ambient" parameters are some sort of context, is to use Monads.

It really depends on your use-case whether that makes sense or not, so let's use an example of Transaction. Instead of passing in some database connection to each function, you could instead return something that needs a database connection. For example:

f :: a -> Transaction b

If you're specifically need to modify some things in each function, a State monad may be the thing you're looking for. Same concept, function will return something that will still need an initial state to "really" run.

Whether that is language agnostic and compose? Well, Haskell has the do notation, Scala has for-comprehensions. If all else fails, you can just use flatMap directly. I've been doing the latter in Java. Works up to a point, but admittedly gets pretty unreadable real fast.

Related Solutions

Functional Programming – What Are ‘Total’ and ‘Partial’ Functions?

Here's a reasonable definition from the Haskell wiki:

A total function is a function that is defined for all possible values of its input. That is, it terminates and returns a value.

A partial function is a function that is not defined for all possible input values; in some cases instead of returning a value, it may never return at all (think infinite cycles), throw an exception (which usually states "this is undefined for this input value" or "unexpected input" or whatever) or simply crash the system.

A well-known example of a partial function is the integer division, a divided by b: it's not defined when b is zero!

Another example is head, the Haskell function that takes the first element of a list, which throws an error if the list is empty! Something like this:

head :: [a] -> a  // this is the signature
head (first : rest) = first
head _ = ... // This is an error! What is the first element of the empty list?

Partial functions like head unfortunately exist in Haskell for historical reasons. Note it can be made total like this:

headMaybe :: [a] -> Maybe a
headMaybe (first : rest) = Just first
headMaybe _ = Nothing

Then you can safely call head [] ([] is the empty list) and it will return Nothing instead of throwing.

Note that when looking at the original head, I cannot know just by looking at its definition that it may throw an error in some cases; I need to look at its implementation instead! That's bad. Compare this with headOption: just by looking at its type I know it sometimes returns a Just x and sometimes a Nothing, and I don't have to examine the implementation.

C# – Should Functions Taking Functions as Parameters Also Take Their Parameters?

If you do this long enough, you'll eventually find yourself writing this function over and over:

public static Type3 CombineFunc1AndFunc2(
    Func<Type1, Type2> func1,
    Func<Type2, Type3>> func2,
    Type1 input)
{
    return func2(func1(input))
}

Congratulations, you've invented function composition.

Wrapper functions like this don't have much use when they're specialized to one type. However, if you introduce some type variables and omit the input parameter, then your GetFormattedRate definition looks like this:

public static Func<A, C> Compose(
    Func<B, C> outer, Func<A, B>> inner)
{
    return (input) => outer(inner(input))
}

var GetFormattedRate = Compose(FormatRate, GetRate);
var formattedRate = GetFormattedRate(rateKey);

As it stands, what you're doing has little purpose. It's not generic, so you need to duplicate that code all over the place. It overcomplicates your code because now your code has to assemble everything it needs from a thousand tiny functions on its own. Your heart's in the right place though: you just need to get used to using these sorts of generic higher order functions to put things together. Or, use a good old fashion lambda to turn Func<A, B> and A into Func<B>.

Don't repeat yourself.

Best Answer

Related Solutions

Functional Programming – What Are ‘Total’ and ‘Partial’ Functions?

C# – Should Functions Taking Functions as Parameters Also Take Their Parameters?

Related Topic