What does 'pure' in functional programming mean if an application mutates the stack?

Question

We know that pure functions:

1. Always return the same result for a given input
2. Produce no side-effects

This leads us to referential transparency - where an expression can be replaced with a value without changing the behaviour of the program.

This tells us that a program can be said to be purely functional if it excludes destructive modifications (updates) of entities in the program's running environment.

This commentator wrote:

grappling with what "pure" in an FP setting actually means, considering application itself is a protocol for mutation (the stack)

My question is: What does 'pure' in functional programming mean if an application mutates the stack?

Answer 1

The fact that the function mutates the stack is a consequence of the implementation of the machine. It doesn't matter for defining pure, just as the fact that using a 'value' requires mutating a register in the processor core doesn't matter.

If a function doesn't mutate (or depend on) anything external to its own stack frame (e.g. global variables, io, randomness), it can still be viewed as pure.