execution-time-vs-purity.md

The time when a program is executed, i.e. compile time or runtime, has nothing to do with whether that program is pure or impure.

• You can execute pure programs at compile time.
• You can execute pure programs at runtime.
• You can execute impure programs at compile time.
• You can execute impure programs at runtime.

For example, consider the following program.

import radius from "./radius.json"; // radius = 10

const areaCircle = radius => Math.PI * radius ** 2;

console.log(areaCircle(radius)); // 314.1592653589793

When you run the above JavaScript program, both the pure parts and the impure parts are executed at runtime. However, we could write a JavaScript compiler which executes parts of the program at compile time. For example, the compiler might inline the areaCircle function call.

import radius from "./radius.json"; // radius = 10

console.log(Math.PI * radius ** 2); // 314.1592653589793

This is an example of pure code being executed at compile time. However, the compiler might also be able to execute impure code at compile time. For example, reading the ./radius.json file is an impure operation which is executed at compile time by module bundlers like webpack.

const radius = 10;

console.log(Math.PI * radius ** 2); // 314.1592653589793

Hence, the following statement is wrong.

In a purely functional programming language like Haskell purity only applies to the compile time, not the runtime

This is not true. The pure parts of a Haskell program can be, and usually are, executed at runtime. GHC will compile pure functions into pure executable code, and when you run the program the CPU would execute the pure code.

Next, the following statement is wrong too.

Javascript is an interpreted language, that is to say you don't have a compile time and hence you cannot separate purity from impurity so elegantly.

Again, the time when a program is executed has nothing to do with whether the program is pure or impure. Just because JavaScript is an interpreted language doesn't mean that you can't separate pure code from impure code. I explained this extensively in my answer.

Finally, the terms “compile-time purity” and “runtime impurity” are quite nonsensical. Pure code is not inherently restricted to the compile time, and impure code is not inherently restricted to the runtime. The compiler can, and usually does, execute impure code at compile time too. For example, when reading imported files. Similarly, pure code can be, and usually is, executed at runtime.

It would help if you understand that the compile time of a program is the same as the runtime of the compiler. After all, the compiler is itself a program. The compiler can execute both pure code and impure code. It can also execute parts of your program before compiling.

The parts of a program which are pure, and the parts which are impure, are determined by the program itself. They are not determined by when the program is executed.