Simon Peyton-Jones: Towards a Programming Language Nirvana

Thanks for this video.
I love listening to programming language gurus. 

awesome

Heh, coincidentally just two days ago I became interested in Haskell - and GHC (Glasgow Haskell Compiler) in particular. I think I'm going to learn it someday when I have more free time.
It's great to see the man behind GHC that has made a lot of work for it. Wish you luck. 

Wonderful video Charles, but no fair, it's way to short! Can we please get Simon back on C9 soon. I read his "Beautiful Concurrency" paper again recently and was struck again by what a great brain / communicator he is (as well as possessing a very sly sense of humour). More Simon...

Wow, thats very cool. Just way too short! I wanted to hear more

Good interview.
   

Great Teaser!

More please.

Yes, more SPJ please!

Brilliant! More of this please. Interesting perspectives, not just bla bla bla.

Charles wrote:



I will try to get more time with Simon. Since he's in Cambridge most of the time, it probably won't be soon, though I do know he's going to a conference not too far from Seattle sometime soon.... I will need to look into this.

Yes, he's going to have a few tutorials and talks at OSCON in Portland which takes place July 23-27, so you best hurry if you want to make arrangements for anything related to that!
According to their website his last talk is on the 25th. Maybe you could invite him up to Seattle after that? Or arrange a road trip

I'd love to hear more talk on general programming languages trends and theory, but also more on the concurrency problem that we face in the future.

Great video!

When will Nirvana.NET be relased?

I listened to the audio version of this video...maybe that was a mistake.

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.

I should note I have never programmed in Haskell, but it looks intriguing.

If you are interedted in Haskell (or anybody), the first step is to read:

http://en.wikibooks.org/wiki/Haskell/YAHT

warning: reading YAHT can cause catharsis, haha

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!

Not only was it nice, informative and too short, but it was just funny!! I laughed a lot... More like this one.

Hehe. I remember back when I was in college. I gave the computing department a great deal of grief for using haskell for "not being a useful language". Hehe. It's really nicely put together tho.

Nirvana...

What a great name for a programming language!