On Thu, Dec 10, 2009 at 6:34 PM, David Leimbach <[email protected]> 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.
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.
Haskell-Cafe mailing list