Is this a pure function?

Question

Most sources define a pure function as having the following two properties:

1. Its return value is the same for the same arguments.
2. Its evaluation has no side effects.

It is the first condition that concerns me. In most cases, it's easy to judge. Consider the following JavaScript functions (as shown in this article)

Pure:

const add = (x, y) => x + y;

add(2, 4); // 6

Impure:

let x = 2;

const add = (y) => {
  return x += y;
};

add(4); // x === 6 (the first time)
add(4); // x === 10 (the second time)

It's easy to see that the 2nd function will give different outputs for subsequent calls, thereby violating the first condition. And hence, it's impure.

This part I get.

---

Now, for my question, consider this function which converts a given amount in dollars to euros:

(EDIT - Using const in the first line. Used let earlier inadvertently.)

const exchangeRate =  fetchFromDatabase(); // evaluates to say 0.9 for today;

const dollarToEuro = (x) => {
  return x * exchangeRate;
};

dollarToEuro(100) //90 today

dollarToEuro(100) //something else tomorrow

Assume we fetch the exchange rate from a db and it changes every day.

Now, no matter how many times I call this function today, it will give me the same output for the input 100. However, it might give me a different output tomorrow. I'm not sure if this violates the first condition or not.

IOW, the function itself doesn't contain any logic to mutate the input, but it relies on an external constant that might change in the future. In this case, it's absolutely certain it will change daily. In other cases, it might happen; it might not.

Can we call such functions pure functions. If the answer is NO, how then can we refactor it to be one?

Answer 1

The dollarToEuro's return value depends on an outside variable that is not an argument; therefore, the function is impure.

If the answer is NO, how then can we refactor the function to be pure?

One option is to pass in exchangeRate. This way, every time arguments are (something, somethingElse), the output is guaranteed to be something * somethingElse:

const exchangeRate =  fetchFromDatabase(); // evaluates to say 0.9 for today;

const dollarToEuro = (x, exchangeRate) => {
  return x * exchangeRate;
};

Note that for functional programming, you should avoid let - always use const to avoid reassignment.

Answer 2

Technically, any program that you execute on a computer is impure because it eventually compiles down to instructions like “move this value into eax” and “add this value to the contents of eax”, which are impure. That's not very helpful.

Instead, we think about purity using black boxes. If some code always produces the same outputs when given the same inputs then it's considered to be pure. By this definition, the following function is also pure even though internally it uses an impure memo table.

const fib = (() => {
    const memo = [0, 1];

    return n => {
      if (n >= memo.length) memo[n] = fib(n - 1) + fib(n - 2);
      return memo[n];
    };
})();

console.log(fib(100));

We don't care about the internals because we are using a black box methodology for checking for purity. Similarly, we don't care that all code is eventually converted to impure machine instructions because we're thinking about purity using a black box methodology. Internals are not important.

Now, consider the following function.

const greet = name => {
    console.log("Hello %s!", name);
};

greet("World");
greet("Snowman");

Is the greet function pure or impure? By our black box methodology, if we give it the same input (e.g. World) then it always prints the same output to the screen (i.e. Hello World!). In that sense, isn't it pure? No, it's not. The reason it's not pure is because we consider printing something to the screen a side effect. If our black box produces side effects then it is not pure.

What is a side effect? This is where the concept of referential transparency is useful. If a function is referentially transparent then we can always replace applications of that function with their results. Note that this is not the same as function inlining.

In function inlining, we replace applications of a function with the body of the function without altering the semantics of the program. However, a referentially transparent function can always be replaced with its return value without altering the semantics of the program. Consider the following example.

console.log("Hello %s!", "World");
console.log("Hello %s!", "Snowman");

Here, we inlined the definition of greet and it didn't change the semantics of the program.

Now, consider the following program.

undefined;
undefined;

Here, we replaced the applications of the greet function with their return values and it did change the semantics of the program. We are no longer printing greetings to the screen. That's the reason why printing is considered a side effect, and that's why the greet function is impure. It's not referentially transparent.

Now, let's consider another example. Consider the following program.

const main = async () => {
    const response = await fetch("https://time.akamai.com/");
    const serverTime = 1000 * await response.json();
    const timeDiff = time => time - serverTime;
    console.log("%d ms", timeDiff(Date.now()));
};

main();

Clearly, the main function is impure. However, is the timeDiff function pure or impure? Although it depends upon serverTime which comes from an impure network call, it is still referentially transparent because it returns the same outputs for the same inputs and because it doesn't have any side effects.

zerkms will probably disagree with me on this point. In his answer, he said that the dollarToEuro function in the following example is impure because “it depends upon the IO transitively.”

const exchangeRate =  fetchFromDatabase(); // evaluates to say 0.9 for today;

const dollarToEuro = (x, exchangeRate) => {
  return x * exchangeRate;
};

I have to disagree with him because the fact that the exchangeRate came from a database is irrelevant. It's an internal detail and our black box methodology for determining the purity of a function doesn't care about internal details.

In purely functional languages like Haskell, we have an escape hatch for executing arbitrary IO effects. It's called unsafePerformIO, and as the name implies if you do not use it correctly then it's not safe because it might break referential transparency. However, if you do know what you're doing then it's perfectly safe to use.

It's generally used for loading data from configuration files near the beginning of the program. Loading data from config files is an impure IO operation. However, we don't want to be burdened by passing the data as inputs to every function. Hence, if we use unsafePerformIO then we can load the data at the top level and all our pure functions can depend upon the immutable global config data.

Note that just because a function depends upon some data loaded from a config file, a database, or a network call, doesn't mean that the function is impure.

However, let's consider your original example which has different semantics.

let exchangeRate =  fetchFromDatabase(); // evaluates to say 0.9 for today;

const dollarToEuro = (x) => {
  return x * exchangeRate;
};

dollarToEuro(100) //90 today

dollarToEuro(100) //something else tomorrow

Here, I'm assuming that because exchangeRate is not defined as const, it's going to be modified while the program is running. If that's the case then dollarToEuro is definitely an impure function because when the exchangeRate is modified, it'll break referential transparency.

However, if the exchangeRate variable is not modified and will never be modified in the future (i.e. if it's a constant value), then even though it's defined as let, it won't break referential transparency. In that case, dollarToEuro is indeed a pure function.

Note that the value of exchangeRate can change every time you run the program again and it won't break referential transparency. It only breaks referential transparency if it changes while the program is running.

For example, if you run my timeDiff example multiple times then you'll get different values for serverTime and therefore different results. However, because the value of serverTime never changes while the program is running, the timeDiff function is pure.

Answer 3

An answer of a me-purist (where "me" is literally me, since I think this question does not have a single formal "right" answer):

In a such dynamic language as JS with so many possibilities to monkey patch base types, or make up custom types using features like Object.prototype.valueOf it's impossible to tell whether a function is pure just by looking at it, since it's up to the caller on whether they want to produce side effects.

A demo:

const add = (x, y) => x + y;

function myNumber(n) { this.n = n; };
myNumber.prototype.valueOf = function() {
    console.log('impure'); return this.n;
};

const n = new myNumber(42);

add(n, 1); // this call produces a side effect

An answer of me-pragmatist:

From the very definition from wikipedia

In computer programming, a pure function is a function that has the following properties:

1. Its return value is the same for the same arguments (no variation with local static variables, non-local variables, mutable reference arguments or input streams from I/O devices).
2. Its evaluation has no side effects (no mutation of local static variables, non-local variables, mutable reference arguments or I/O streams).

In other words, it only matters how a function behaves, not how it's implemented. And as long as a particular function holds these 2 properties - it's pure regardless how exactly it was implemented.

Now to your function:

const exchangeRate =  fetchFromDatabase(); // evaluates to say 0.9 for today;

const dollarToEuro = (x, exchangeRate) => {
  return x * exchangeRate;
};

It's impure because it does not qualify the requirement 2: it depends on the IO transitively.

I agree the statement above is wrong, see the other answer for details: https://stackoverflow.com/a/58749249/251311

Other relevant resources:

• Referential transparency

Answer 4

Like other answers have said, the way you have implemented dollarToEuro,

let exchangeRate = fetchFromDatabase(); // evaluates to say 0.9 for today;

const dollarToEuro = (x) => { return x * exchangeRate; }; 

is indeed pure, because the exchange rate is not updated while the program is running. Conceptually, however, dollarToEuro seems like it should be an impure function, in that it uses whatever the most up to date exchange rate is. The simplest way to explain this discrepancy is that you have not implemented dollarToEuro but dollarToEuroAtInstantOfProgramStart - the key here is that there are several parameters that are required to calculate a currency conversion, and that a truly pure version of the general dollarToEuro would supply all of them.

The most direct parameters you could provide, as other answers suggest, are the amount of USD to convert, and the exchange rate of how many euro per dollar:

const dollarToEuro = (x, exchangeRate) => x * exchangeRate;

However, such a function is pretty pointless - a caller of dollarToEuro will be calling it precisely because they do not know the exchange rate, and expect dollarToEuro to know the rate and apply it to their desired currency exchange.

There is, however, something else we know: at any given instant, the exchange rate will always be the same, and if you have a source (perhaps, a database) that publishes the exchange rates as they change, then we can look up that source by date and figure out what the exchange rate is going to be on any particular day. In code, what this would translate to is providing a date parameter to your fetchFromDatabase() function:

function fetchFromDatabase(date) {
    // make the REST call to the database, providing the date as a parameter ...
    // once it's done, return the result
}

If the database always returns the same result for the exchange rate when given the same date input, then fetchFromDatabase() is pure. And with such a function, you can now have a function that looks like this:

const dollarToEuro = (x, date) => {
    const exchangeRate = fetchFromDatabase(date);
    return x * exchangeRate;
}

and it too would be pure.

Now, going back to your original function. If we rewrite it into this new framework of this new dollarToEuro(x, date), it would look like this:

const programStartDate = Date.now();

const dollarToEuroAtInstantOfProgramStart = (x) => { 
    return dollarToEuro(x, programStartDate); 
}

If instead we wanted to write a function which converts the currency using the most up-to-date value in the database, we would write something like:

const dollarToEuroUpToDate = (x) => { return dollarToEuro(x, Date.now()); }

This function would not be pure, because (and only because) Date.now() is not pure - and that's exactly what we expect.

Answer 5

I’d like to back out a bit from the specific details of JS and the abstraction of formal definitions, and talk about which conditions need to hold to enable specific optimizations. That’s usually the main thing we care about when writing code (although it helps prove correctness, too). Functional programming is neither a guide to the latest fashions nor a monastic vow of self-denial. It is a tool to solve problems.

When you have code like this:

let exchangeRate =  fetchFromDatabase(); // evaluates to say 0.9 for today;

const dollarToEuro = (x) => {
  return x * exchangeRate;
};

dollarToEuro(100) //90 today

dollarToEuro(100) //something else tomorrow

If exchangeRate could never be modified in between the two calls to dollarToEuro(100), it is possible to memo-ize the result of the first call to dollarToEuro(100) and optimize away the second call. The result will be the same, so we can just remember the value from before.

The exchangeRate might be set once, before calling any function that looks it up, and never modified. Less restrictively, you might have code that looks up the exchangeRate once for a particular function or block of code, and uses the same exchange rate consistently within that scope. Or, if only this thread can modify the database, you would be entitled to assume that, if you did not update the exchange rate, no one else has changed it on you.

If fetchFromDatabase() is itself a pure function evaluating to a constant, and exchangeRate is immutable, we could fold this constant all the way through the calculation. A compiler that knows this to be the case could make the same deduction you did in the comment, that dollarToEuro(100) evaluates to 90.0, and replace the entire expression with the constant 90.0.

However, if fetchFromDatabase() does not perform I/O, which is considered a side-effect, its name violates the Principle of Least Astonishment.

Answer 6

To expand on the points others have made about referential transparency: we can define purity as simply being referential transparency of function calls (i.e. every call to the function can be replaced by the return value without changing the semantics of the program).

The two properties you give are both consequences of referential transparency. For example, the following function f1 is impure, since it doesn't give the same result every time (the property you've numbered 1):

function f1(x, y) {
  if (Math.random() > 0.5) { return x; }
  return y;
}

Why is it important to get the same result every time? Because getting different results is one way for a function call to have different semantics from a value, and hence break referential transparency.

Let's say we write the code f1("hello", "world"), we run it and get the return value "hello". If we do a find/replace of every call f1("hello", "world") and replace them with "hello" we will have changed the semantics of the program (all of the calls will now be replaced by "hello", but originally about half of them would have evaluated to "world"). Hence calls to f1 are not referentially transparent, hence f1 is impure.

Another way that a function call can have different semantics to a value is by executing statements. For example:

function f2(x) {
  console.log("foo");
  return x;
}

The return value of f2("bar") will always be "bar", but the semantics of the value "bar" are different from the call f2("bar") since the latter will also log to the console. Replacing one with the other would change the semantics of the program, so it's not referentially transparent, and hence f2 is impure.

Whether your dollarToEuro function is referentially transparent (and hence pure) depends on two things:

• The 'scope' of what we consider referentially transparent
• Whether the exchangeRate will ever change within that 'scope'

There is no "best" scope to use; normally we would think about a single run of the program, or the lifetime of the project. As an analogy, imagine that every function's return values get cached (like the memo table in the example given by @aadit-m-shah): when would we need to clear the cache, to guarantee that stale values won't interfere with our semantics?

If exchangeRate were using var then it could change between each call to dollarToEuro; we would need to clear any cached results between each call, so there would be no referential transparency to speak of.

By using const we're expanding the 'scope' to a run of the program: it would be safe to cache return values of dollarToEuro until the program finishes. We could imagine using a macro (in a language like Lisp) to replace function calls with their return values. This amount of purity is common for things like configuration values, commandline options, or unique IDs. If we limit ourselves to thinking about one run of the program then we get most of the benefits of purity, but we have to be careful across runs (e.g. saving data to a file, then loading it in another run). I wouldn't call such functions "pure" in an abstract sense (e.g. if I were writing a dictionary definition), but have no problem with treating them as pure in context.

If we treat the lifetime of the project as our 'scope' then we're the "most referentially transparent" and hence the "most pure", even in an abstract sense. We would never need to clear our hypothetical cache. We could even do this "caching" by directly rewriting the source code on disk, to replace calls with their return values. This would even work across projects, e.g. we could imagine an online database of functions and their return values, where anyone can look up a function call and (if it's in the DB) use the return value provided by someone on the other side of the world who used an identical function years ago on a different project.

Answer 7

This function is not pure, it relies on an outside variable, which is almost definitely going to change.

The function therefore fails the first point you made, it does not return the same value when for the same arguments.

To make this function "pure", pass exchangeRate in as an argument.

This would then satisfy both conditions.

1. It would always return the same value when passing in the same value and exchange rate.
2. It would also have no side effects.

Example code:

const dollarToEuro = (x, exchangeRate) => {
  return x * exchangeRate;
};

dollarToEuro(100, fetchFromDatabase())

Answer 8

As written, it is a pure function. It produces no side effects. The function has one formal parameter, but it has two inputs, and will always output the same value for any two inputs.

Answer 9

Can we call such functions pure functions. If the answer is NO, how then can we refactor it to be one?

As you duly noted, "it might give me a different output tomorrow". Should that be the case, the answer would a resounding "no". This is especially so if your intended behaviour of dollarToEuro has been correctly interpreted as:

const dollarToEuro = (x) => {
  const exchangeRate =  fetchFromDatabase(); // evaluates to say 0.9 for today;
  return x * exchangeRate;
};

However, a different interpretation exists, where it would be considered pure:

const dollarToEuro = ( () => {
    const exchangeRate =  fetchFromDatabase();

    return ( x ) => x * exchangeRate;
} )();

dollarToEuro directly above is pure.

---

From a software engineering perspective, it's essential to declare the dependency of dollarToEuro on the function fetchFromDatabase. Therefore, refactor the definition of dollarToEuro as follows:

const dollarToEuro = ( x, fetchFromDatabase ) => {
  return x * fetchFromDatabase();
};

With this outcome, given the premise that fetchFromDatabase functions satisfactorily, then we can conclude that the projection of fetchFromDatabase on dollarToEuro must be satisfactory. Or the statement "fetchFromDatabase is pure" implies dollarToEuro is pure (since fetchFromDatabase is a basis for dollarToEuro by the scalar factor of x.

From the original post, I can understand that fetchFromDatabase is a function time. Let's improve the refactoring effort to make that understanding transparent, hence clearly qualifying fetchFromDatabase as a pure function:

fetchFromDatabase = ( timestamp ) => { /* here goes the implementation */ };

Ultimately, I would refactor the feature as follows:

const fetchFromDatabase = ( timestamp ) => { /* here goes the implementation */ };

// Do a partial application of `fetchFromDatabase` 
const exchangeRate = fetchFromDatabase.bind( null, Date.now() );

const dollarToEuro = ( dollarAmount, exchangeRate ) => dollarAmount * exchangeRate();

Consequently, dollarToEuro can be unit-tested by simply proving that it correctly calls fetchFromDatabase (or its derivative exchangeRate).

Answer 10

As the top answer says, reading a mutable value is generally considered impure and you can refactor to include the exchange rate. What is not stated is that sometime later you will need an impure function to do real work in the impure world, something like

async function buyCoins(user: User, package: CoinPackage) {
  // Random number generation is impure
  const id = uuidv4();
  // Fetching from a DB is impure,
  const exchageRates = await knex.select('*').from('ExchangeRates');
  // usdFromPrice can be a pure function
  const usdEstimate = usdFromPrice(package.price, exchangeRates);
  // but getting a date is not
  const createdDate = Date.now() / 1000;
  // Saving to a DB is more obviously impure
  const coinTransfer = { id, user, package, state: "PENDING", usdEstimate, createdDate };
  await knex('CoinTransfers').insert(coinTransfer);
  // ...
}

Reading from mutable values, or reading dates or random numbers, can be seen to be impure by a very easy criterion. Why do we like purity? Because pure functions can be composed, cached, optimized, inlined, and most importantly tested in isolation. This is why mocking is so popular, mocks turn an effectful computation into a pure one, allowing unit tests and so forth.

Testing is a great way to ask if you have a pure function. In your case I might write a test, “confirm that 10€ is 11.93 US$” and this test breaks tomorrow! So I have to mock the side-effect, which proves that there was one. Dates are side-effects, sleep()ing is a side effect, these things have no real expressibility in the abstract world of lambda calculus—and you can see this from the fact that you might wish to mock time, for instance to test things like “you can edit a tweet for 15 minutes after you send it, but after that edits should be frozen.”

What does pure-by-default look like?

In languages like Haskell we strive for purity by default, you can still write your const rate = getExchangeRate() line up-top but it requires a function called unsafePerformIO, it has the word “unsafe” right there in the name. So for example, I might be writing a Choose-Your-Own-Adventure style game, I might include a file pages.json that has my level data, and roughly speaking I can say “I know that pages.json always exists and does not change meaningfully in the course of my game,” and so here I would permit myself some impurity: I would read in that file with unsafePerformIO. But most of the things I would write, I would not write with direct side-effects. To encapsulate such side-effects in Haskell we do something that you could call metaprogramming, writing programs with other programs—except that sadly, today metaprogramming usually refers to macros (rewriting source code trees with other source code) which is much more powerful and dangerous than this simpler sort of metaprogramming.

Haskell wants you to write out a pure computation which will compute a value called Main.main, whose type is IO (), or “a program producing no values.” Programs are just one of the data types that I can manipulate in Haskell. Then, it is the Haskell compiler's job to give this to take this source file, perform that pure computation, and put that effectful program as a binary executable somewhere on your hard drive to be run later at your leisure. There is a gap, in other words, between the time when the pure computation runs (while the compiler makes the executable) and the time when the effectful program runs (whenever you run the executable).

For a very lightweight example (i.e. not full-featured, not production-ready) of a TypeScript class which describes immutable programs and some stuff you can do with them, consider

export class Program<x> {
  // wrapped function value
  constructor(public readonly run: () => Promise<x>) {}

  // promotion of any value into a program which makes that value
  static of<v>(value: v): Program<v> {
    return new Program(() => Promise.resolve(value));
  }
  // applying any pure function to a program which makes its input
  map<y>(fn: (x: x) => y): Program<y> {
    return new Program(() => this.run().then(fn));
  }
  // sequencing two programs together
  chain<y>(after: (x: x) => Program<y>): Program<y> {
    return new Program(() => this.run().then(x => after(x).run()));
  }
  // maybe we also play with overloads and some variable binding
  bind<key extends string, y>(name: key, after: Program<y>): Program<x & { [k in key]: y }>;
  bind<key extends string, y>(name: key, after: (x: x) => y): Program<x & { [k in key]: y }>;
  bind<key extends string, y>(name: key, after: (x: x) => Program<y>): Program<x & { [k in key]: y }>;
  bind<key extends string, y>(name: key, after: Program<y> |  ((x: x) => Program<y> | y)): Program<x & { [k in key]: y }> {
    return this.chain((x) => {
        if (after instanceof Program) return after.map((y) => ({ [name]: y, ...x })) as any;
        const computed = after(x);
        return computed instanceof Program? computed.map(y => ({ [name]: y, ...x }))
          : Program.of({[ name ]: computed as y, ...x });
    });
  }
}

The key is that if you have a Program<x> then no side effects have happened and these are totally functionally-pure entities. Mapping a function over a program does not have any side effects unless the function was not a pure function; sequencing two programs does not have any side effects; etc.

Then our above function might start to be written like

function buyCoins(io: IO, user: User, coinPackage: CoinPackage) {
  return Program.of({})
    .bind('id', io.random.uuidv4)
    .bind('exchangeRates', io.biz.getExchangeRates)
    .bind('usdEstimate', ({ exchangeRates }) =>
      usdFromPrice(coinPackage.price, exchangeRates)
    )
    .bind(
      'createdDate',
      io.time.now.map((date) => date.getTime() / 1000)
    )
    .chain(({ id, usdEstimate, createdDate }) =>
      io.biz.saveCoinTransfer({
        id,
        user,
        coinPackage,
        state: 'PENDING',
        usdEstimate,
        createdDate,
      })
    );
}

The point is that every single function here is a completely pure function; indeed even a buyCoins(io, user, coinPackage) is a Program and nothing has actually happened until I actually .run() to set it into motion.

On the one hand there is a big cost to pay to start using this level of purity and abstraction. On the other hand you might be able to see that the above allows effortless mocking -- just change the io parameter to one that runs things differently. For example, instead of the production values which might look like

// module io.time
export now = new Program(async () => new Date());
export sleep = new Program(
  (ms: number) => new Promise(accept => setTimeout(accept, ms)));

you can for testing mock in a value that does not actually sleep, and has deterministic dates otherwise:

function mockIO(): IO {
  let currentTime = 1624925000000;
  return {
    // ...
    time: {
      now: new Program(async () => new Date(currentTime)),
      sleep: (ms: number) => new Program(async () => {
        currentTime += ms;
        return undefined;
      })
    }
  };
}

In other languages/frameworks you might instead do this by a large heaping of reflection and autowiring dependency-injection; those work but they involve quite fancy layers of code to enable the basic functionality; by contrast the indirection created by just defining the 30-line class Program<x> is already strong enough to allow all of this mocking directly, because we're not trying to inject dependencies but merely provide them, which is a much simpler goal.

Answer 11

I have questions as to how useful it is to classify such a function as pure, as if I start using it with other "pure functions" there is going to be some interesting behavior at some point.

I think I prefer "pure" to have the implication I can compose it with no unexpected behavior.

Here's what I would consider a "functional core" for this:

    // builder of Rates Expressions, only depends on ```map```
    const ratesExpr = (f) => (rates => rates.map(f))
    // The actual pure function
    const dollarToEuro = (x) => ratesExpr( r => r.usd.eur * x)

    // base interpreter of Rates Expressions
    const evalRatesExpr = fetcher => expr => expr([fetcher()])

And the imperative shell:

    // various interpreters with live/cached data
    const testRatesExpr = evalRatesExpr( () => { usd = { eur = 2.0 }} )
    const cachedRates = fetchFromDatabase()
    const evalCachedRatesExpr = evalRatesExpr(() => cachedRates)
    const evalLiveRatesExpr = evalRatesExpr( fetchFromDatabase )

    // Some of these may pass...
    assert (testRatesExpr(dollarToEuro(5))) === [10]      //Every time 
    assert (evalLiveRatesExpr(dollarToEuro(5)) === [8]     //Rarely
    assert (evalCacheRatesExpr(dollarToEuro(5)) === [8.5]  //Sometimes

Without types it's a bit hard to make the whole thing stick together. I would consider this some sort of "final tagless" and "monadic" combination.