On Mon, Mar 12, 2012 at 04:58, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Sun, 11 Mar 2012, Brandon Allbery wrote:
The context is that getEnv currently throws an IO exception if the name isn't found, and we'd like it
to be IO (Maybe String) because it's really a keyed store where absence of
the key isn't really justification for an IO exception, but is a reasonable use for a Maybe. It's the cranky IO exception that needs to go away, not the notion of an exceptional condition in general.
I replied to Conrad Parker who said "+1 to the general concept of not using Haskell exceptions in library code." and John Lato who said something similar. If they refer with "Haskell exceptions" to the exceptions that are implicit in the IO monad, then I support this proposal. That's the context I refered to.
It was pretty clear to me, following form the start, that Control.Exception was meant. I will, however, note that while referring to out of band data as "exceptional" is in some sense pedantically correct, it also leads to precisely *this* confusion. Commonly an "exception" is understood as a form of non-local goto that propagates into a runtime abort if not handled appropriately, not simply an out of band datum indicating e.g. the absence of a value; bringing the pedantic definition into a random discussion, at least without establishing relevance, engenders confusion instead of reducing it.
Currently there is no one planning to use MaybeT in System.Environment, since this would mean to make base/haskell2010 depend on transformers. But an option might be to start a package where generally IO exceptions are replaced by MaybeT and its friends. Then we could leave System.Environment as it is.
Some things in IO are reasonably Control.Exception, and some things aren't. (Yay, sewer.) Although at least some things that are reasonably Control.Exception might lead to simplified code in some use cases if expressed with MaybeT, this must be done carefully as many things are not safely characterized as such; in particular, I'm wondering if having handle-close return an out of band failure instead of a Control.Exception implies a causal relationship that may not exist (as the close() may be indicating that a prior write() failed — not that the close() itself failed — in particular with sockets). -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms