Simon Peyton-Jones: Towards a Programming Language Nirvana

pepper wrote:

It is interesting to see what they consider "safe" and "unsafe", but wouldn't the scope and type of a variable inherently limit the extent of its "side effects"? And the same with functions? Perhaps a better definition of "safe" is in order.

Well yes, maybe. Depends on what you mean. E.g. in C you can include IO functions and call them anywhere you want (the hard disk, network drives etc. are all "mutable variables" in a sense) so in order to be safe you must have a language which separates "IO actions" from "pure computations" (otherwise you could in principle make several calls to "sin" or something and get different results for the same input values, if "sin" reads from disk or a network socket or whatever).

Also scope of variables can change dynamically. E.g. what if a function returns a mutable reference? Then this mutable reference can be accessed from outside the function it was created in. So in order to be safe the language must statically ensure that no such "leaking" of side effects can occur.

So Haskell does all of this. You have an "IO monad" where you define "IO actions". A monad is pretty simple actually, but it's such a general concept that it can be difficult to get a handle on it. Essentially you have a data type representing your monad, and two functions on it. One of them takes "something" and makes it into a "monadic something". And the other takes two "monadic somethings" and combines them into one "monadic somehting". Monads can be used to model lots of things, such as collections (e.g. that LINQ stuff is heavily based on this), but in this case the monad is used to model "IO actions". In other words "actions which, if performed, will do some IO". Note that you're not actually doing any IO when using the two monadic functions described above, you're only building actions which represent the IO you want to do.

Anyway, the point is that there is no way of actually performing this IO "outside" of this IO monad. The only way of doing IO is to take smaller IO actions and combining them into larger IO actions (using the function mentioned above). But there is no way to "run" an IO action from within Haskell (you effectively give the IO action representing your program to the compiler, which will produce the necessary code to run it, but you the programmer has no way of running IO actions). This means that IO actions "infect" anything that uses them; the only way to use an IO action is within another IO action.
So "sin" must be pure and completely free from side effects because its type doesn't say that it's an IO action.
Of course IO actions are perfectly free to call pure functions to do computations, but the opposite is statically ensured to never happen.

That's one part of the puzzle.

The other cool thing is that if you only want to do mutable state (and not, e.g. read from a network socket or do any other IO) then you can use the "ST" monad. This is like the IO monad except it only allows you to read and write to mutable variables (and arrays etc.), and it also gives you a function called "runST" which runs and ST action. This means that you can actually call such an ST action from pure code (unlike IO). The key thing here is that runST has a type which prevents side effects from "leaking" (so you can't e.g. call runST on an ST action which returns a mutable reference). So while you may have lots of ST actions which read and write to lots of mutable references in scope, there is no way that any such side effects can "leak" through "runST". This means you can write algorithms with mutable state (and there are algorithms where this is requried) but then once you're done you wrap it in a pure interface (same input => same output) and call "runST" on it to convert it into a pure function that can be called from any pure function.

This way we still get purity (the compiler can do all sorts of cool stuff; but perhaps more importantly the programs are much easier to understand and usually contain far fewer errors -- not to mention the benefits to concurrent programming this gives), but we also have the pragmatics of being able to do low-level mutable state programming where needed.

So while pure functionaly programming used to mean "no mutable state ever" (and as SPJ said, this was the cause of prolonged embarassement before they figured out the monad stuff!), now days it just means "safe mutable state that can be encapsulated in a pure functional environment", which is much more useful!