[simonh]

Ok so run up an embedded OS and application on a system with limited resources so that all the memory is being used. Now run your pure functional program. The system crashes. Using memory is a side effect. Consuming CPU time is a side effect. Heating up the environment and drawing power due to that CPU usage is a side effect[0]. These are not trivial either, actual real systems used for critical activities fall prey to this sort of thing all the time. It just depends on what you are willing to consider as a side effect.

[0]https://xkcd.com/1172/

[jcora]

That's not what purity refers to! We're talking about a mathematical property of the language itself.

The real issue is that people don't understand that `putStrLn "hello"` _is literally just as pure as `2*x`_. They are both like mathematical expressions in that they evaluate to a value and _nothing else_. The name "putStrLn" _suggests_ that this is similar to a print statement but it is emphatically not. You can evaluate it a billion times and nothing gets printed.

[matt_kantor]

Hang on a minute.

The only difference is that the languages you are talking about have captured "doing I/O" as something that can be statically reasoned about, but not "consuming memory" (for example). From a mathematical perspective, one is part of the axioms while another is not.

One could imagine a language where all memory allocation must be done explicitly via a monad, just like how in Haskell all I/O is performed inside an IO monad. If that were the case, you could have additional static guarantees about how memory is used. That doesn't mean that languages which don't do this are somehow inherently "impure"; they are simply "pure with respect to a certain set of axioms" (which don't talk about memory usage).

"The system crashed" example is fun too. All pure functions must return a value, right? Well, that's obviously not gong to be the case if the computer blows up halfway through executing a pure function. "Blowing up" might not be something your type system talks about—Haskell does to some degree (with _|_ inhabiting every type), but Idris for example has total functions which at runtime could most definitely be interrupted by a sudden explosion. They are "total" only with respect to a set of axioms which imply an execution model where computers do not explode mid-program.

[jcora]

This can be done, for example ST in Idris which lets you reason about resources (check out linear types).

However, if you are thinking more in the direction of "you have to reason about where and how exactly your values and functions are stored", you're moving back to C, because the entire point is to disentangle the formal description of computation, from it's actual execution in the real world. If you want to deal with that, you have to do it explicitly and _by reasoning about it_ (with ST, for example). Which is what purity means.

> They are "total" only with respect to a set of axioms which imply an execution model where computers do not explode mid-program

"There is a chance that the computer blows up" is one of those things that have little bearing when reasoning about programs, it's just not in the domain of discourse. It certainly has no formal bearing on the notion of totality, mathematics just doesn't deal with cases such as "what if everyone who counted to 5 suddenly died", it deals with the counting itself. When the chance is actually high, for example radiation in space flipping bits, I'm pretty sure you want to handle that elsewhere.

It's not hard to imagine a fault-tolerance system gaining a lot from dependent types, however, with their ability to prove that your code follows a defined protocol.

[DonHopkins]

Actually, the Moveable Feast Machine is a "Robust First" asynchronous distributed fault tolerant cellular-automata-like computer architecture that DOES reason about what might happen if computers randomly explode in mid-program!

(One of my favorite topics, that I've written about in other threads!)

https://news.ycombinator.com/item?id=15560845

Check out how the city seamlessly regrows after you nuke it:

https://www.youtube.com/watch?v=XkSXERxucPc

> Robust-first Computing: Distributed City Generation: A rough video demo of Trent R. Small's procedural city generation dynamics in the Movable Feast Machine simulator. See http://nm8.us/q for more information.

And here's a robust, self-healing membrane, that tolerates random failures (like tiny little exploding computers):

https://www.youtube.com/watch?v=oq0uvF4mm7Y

>To demonstrate the robustness of three membrane implementations in the MFM, an instance of each was placed side by side and subjected to a failure probability of 5e-5 per site per EPS. That is, each site is erased, on average, every 20,000 event cycles.

Intercellular Transport also demonstrates some robust chemical and biological programming metaphors:

https://www.youtube.com/watch?v=6YucCpYCWpY

>Two cells are interconnected by self-healing wire. The magenta substance is being passed from the cell in the west to the cell in the east. The black particles are an ectoplasm, allowing the membrane to identify sites outside of the cell. Similarly, the yellow and blue particles are an endoplasm specific to the cell in which they reside, allowing the membrane to identify sites inside of it.

Demon Horde Sort exemplifies the Robust First approach:

https://www.youtube.com/watch?v=helScS3coAE

Into functional programming? Here's a demo of programming the Movable Feast Machine with λ-Codons:

https://www.youtube.com/watch?v=DauJ51CTIq8

>λ-Codons provide a mechanism for describing arbitrary computations in the Movable Feast Machine (MFM). A collection of λ-Codon molecules describe the computation by a series of primitive functions. Evaluator particles carry along a stack of memory (which initially contains the input to the program) and visit the λ-Codons, which they interpret as functions and apply to their stacks. When the program completes, they transmute into output particles and carry the answer to the output terminals (left).

[simonh]

Yes we all know that, we're not stupid and the OP clearly knows that perfectly well too, but note his use of the word 'exist'. Real programs don't run on server farms located in Plato's Realm of Forms.