It makes sense to mark something "unsafe" (aka. tainted = coming from an non-trusted source), but what makes it safe differs.

The Haskell concept of 'Unsafe' is quite different from tainting. And it is quite complex to explain.

In part it is to do with substitutability. A Haskell compiler uses term rewriting to 'reduce' programs at compile time. So, in the same way that a C compiler might substitute the number 86400 in place of the source code calculation 24*60*60, the Haskell compiler can and will calculate the result of whole complex functions and substitute the result everywhere that function is called; and do this recursively until -- in effect -- the entire result of the program has been calculated at compile time and the resultant program is nothing more than a single constant or set of constants.

It can do this because in Haskell, functions are "pure". That is, they will always produce the same result for a given set of inputs and they don't have side-effects. Because of the lack of side-effects, the compiler is free to reorder the entire program in whatever way it sees fit. And because of the determinacy of purity, the entire program can be reduced at compile time.

Of course, "constant" programs aren't very useful. To be useful, a program has to accept data from external sources, and return results to the outside world based upon those inputs. And there immediately you've had to introduce impurity into the system.

You cannot completely reduce functions, even pure functions, at compile time, if you don't know what its argument values will be until runtime; you also cannot reorder the program to produce its outputs prior to obtaining its inputs; and both those operations -- input & output -- have side-effects. Input (for example) may move a file-pointer; therefore the input function if called again with the same values will return different results; it is therefore impure -- and "Unsafe". Ditto, writing output to disk or screen, changes that output medium in some way, and if the output function is called again with the same arguments, it has a different affect on the outside world. Therefore impure and unsafe.

Essentially, any data that isn't hard-coded into the source of the program is unsafe.

But it goes further than that. To append an externally derived integer to an internal (hard-coded and therefore safe) string effectively means that the result has to become unsafe. In effect it has to change its type. And changing the type of something is an anathema to type-safety theory. So then you have to introduce weird and obscure theorems -- the Monad -- to the process of allowing the pure and impure -- safe and unsafe -- to interact within a program, so as not to violate the provability of the programs produced.

And it is at that point that things start to get complicated. Programming start to become less about solving real-world problems and more about satisfying obscure and mostly irrelevant theorems -- that maybe a few dozen people in the world really understand, though many more pretend to. Whilst there is some evidence that the splitting of programs into two distinct sets of operations -- those that can be resolved at compiler time and those that cannot, can allow for "elegant" source code to result in efficient and safe runtime code; the Haskell means of arriving there results in a language that is out of reach -- intellectually -- from your average programmer.

The means has become and end unto itself.

But Haskell is not alone in this. Theoretically nice-to-have, monocultures are beginning to crop up in languages all over. Whether it is const correctness in C++; type-safety in Java; a rejection of exceptions in GO; or Only-OO in Perl. Theory is overtaking pragmatism at a time when the cost of development practices are under increasing scrutiny, placing unproven theoretical goals ahead of getting the job done is very short sighted.

So all this is supposed to be another way to interface the purely functional stuff with the rest of the world without the use of monads? Do you have any links to a longer explanation? It's been years since I did work with a purely functional language and it was (Concurrent) Clean which takes a wholly different approach to IO in a purely functional language, but I'd still like to learn more.

Jenda
Enoch was right!
Enjoy the last years of Rome.

So all this is supposed to be another way to interface the purely functional stuff with the rest of the world without the use of monads?

No. As far as I can tell, the author that originated thread containing the post I linked was attempting to achieve something akin to taint-checking vai a mechanism he dubbed "Intent typing", which doesn't seem to appear on the internet outside of his reference.

However, as I attempted to describe, the concept of "Unsafe" in Haskell goes much deeper. A salient reference: This is the "back door" into the IO monad, allowing IO computation to be performed at any time.

Unfortunately, it leaves out the explanation of why it is necessary to incorporate this "backdoor" into the language.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?