[Haskell] Mixing monadic and non-monadic functions

Graham Klyne GK at ninebynine.org
Tue Mar 23 21:09:16 EST 2004

At 12:55 23/03/04 -0500, Sean E. Russell wrote:
>On Tuesday 23 March 2004 11:36, Graham Klyne wrote:
> > I think you're a rather stuck with the "temporary variables" (which they'=
> > not really), but it might be possible to hide some of the untidiness in an
> > auxiliary monadic function.
>That seems to be the common suggestion: write my own visitors.
>I'm just surprised that there isn't a more elegant mechanism for getting=20
>interoperability between monadic and non-monadic functions.  The current=20
>state of affairs just seems awkward. =20
>[Warning: quasi-rant]
>Caveat: I'm not smart enough, and I don't know enough, to criticize Haskell=
>so please don't misconstrue my comments.  To quote Einstein: "When I'm aski=
>simple questions and I'm getting simple answers, I'm talking to God."  I=20
>simply mistrust, and therefore question, systems where simple things are=20
>overly involved.
>The standard explaination about why monads are so troublesome always sounds=
>like an excuse to me.  We have monads, because they allow side-effects.  Ok=
>=2E =20
>If programs that used side effects were uncommon, I'd be fine with them bei=
>troublesome -- but they aren't.  Maybe it is just me, but my Haskell progra=
>invariably develop a need for side effects within a few tens of lines of=20
>code, whether IO, Maybe, or whatnot.  And I can't help but think that=20
>language support to make dealing with monads easier -- that is, to integrat=
>monads with the rest of the language, so as to alleviate the need for=20
>constant lifting -- would be a Good Thing.

I'd make one further point in response... I don't think the "heavy lifting" 
here is because of Monads in general:  some Monads (Maybe, lists, etc) mix 
very easily with pure functional code.  I think it's the IO Monad in 
particular:  here you are creating interactions between two fundamentally 
different environments:  the real-world, which is fundamentally stateful 
and non-referentially-transparent, and mathematical functions that are 
quite the opposite.

>Hmmm.  Could I say that Haskell requires "heavy lifting"?



Graham Klyne
For email:

More information about the Haskell mailing list