On Thu, Dec 10, 2009 at 6:34 PM, David Leimbach
2b. You can define brand new flow control constructs *inside* the language itself. (E.g., in Java, a "for" loop is a built-in language construct. In Haskell, "for" is a function in Control.Monad. Just a plain ordinary function that anybody could write.)
Psst, heard about Scheme & call/cc?
But, very importantly, purity allows you to *restrict* the flow constructs that client code has available. If you have continuations + mutable state you can do anything, but the more code can *do*, the less you *know* about it. For example, providing parser combinators as an applicative functor offers more power than a traditional parser generator, but not enough that we can no longer parse efficiently.
Exactly my fear over unsafePerformIO in 3rd party Haskell libraries :-). One can present an interface in Haskell that looks safe, but it can be very unsafe in its implementation.
Hear, hear! I always meet with armies of resistance when I say this, but unsafePerformIO should die a horrible, unforgiven death. "Well what if you want blah blah blah with a pure interface?" My response: too fscking bad! If you have a pure interface, great, that means your semantics is pure, which has some nice advantages, but your implementation ain't so bite the bullet. Oh you have a proof that it is well behaved? I doubt it, because you can't prove diddly about IO because it has no specified semantics. You get a lot more from purity than just the interface. Pure code can be freely modulated by evaluation strategy (as long as semantic strictness is preserved), serialized, and verified (in the 100%-certain sort of way) with free theorems. You lose all of that when you allow even supposedly-pure-interface unsafePerformIO. unsafeCoerce, too, of course. Luke