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.