> As a consequence, functional programming is also programming with (immutable) values I'll go even further: Values don't exist in time (when did the number 2

> As a consequence, functional programming is also programming with (immutable) values I'll go even further: Values don't exist in time (when did the number 2 suddenly come into existence?), so it doesn't even make sense to ask whether they're “mutable” or “immutable”, which is intrinsically about how objects evolve in time. Values exist in the semantics of the programming language in question (a timeless mathematical object!), and a structural operational semantics makes this very clear: a value is a term that a variable can be substituted with. Ergo: (0) In a call-by-value language, a value is the result of a successful computation. (1) In a call-by-name language, a value is a snapshot of a potentially unfinished computation. (2) In a call-by-need language, a value is the identity of a potentially unfinished computation. (3) In an object-oriented language, the only values are object identities, and the few lucky primitives that escaped being treated as objects. > (i.e. persistent data-structures, etc). You can have ephemeral data structures in a purely functional program too, provided the language has substructural types.