[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'=
>re
> > 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=
>,=20
>so please don't misconstrue my comments. To quote Einstein: "When I'm aski=
>ng=20
>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=
>=20
>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=
>ng=20
>troublesome -- but they aren't. Maybe it is just me, but my Haskell progra=
>ms=20
>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=
>e=20
>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"?
:-)
#g
------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
More information about the Haskell
mailing list