Proposal: System.Environment.getEnv should return Maybe

[Brandon Allbery]

On Mon, Mar 12, 2012 at 04:58, Henning Thielemann <
lemming at 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 at gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120313/f62e5759/attachment.htm>