[Haskell-cafe] Why?

[Luke Palmer]

On Thu, Dec 10, 2009 at 6:34 PM, David Leimbach <leimy2k at gmail.com> wrote:
>>
>> >> 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