On Sun, Mar 11, 2012 at 14:12, Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Fri, 24 Feb 2012, Conrad Parker wrote:

...

On 23 February 2012 20:18, John Lato wrote:

...

This irritates me too; I don't think that Haskell exceptions should be used for much of anything, exceptional condition or not.

+1 to the general concept of not using Haskell exceptions in library code.

This depends on what you call "exception". The exception handling part of the IO monad? The general concept of an exceptional situation? I think if you request the value of a variable, but that variable turns out to not exist, then the question was not valid and that is somehow an exceptional situation.

Is looking up a missing key in a Map an exception? That is exactly this case ("variable" is really only an appropriate term from the standpoint of the shell, which [sometimes inappropriately] conflates the environment with its own variables). Or are you arguing that that also should be an exception? -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On Sun, Mar 11, 2012 at 16:33, Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Sun, 11 Mar 2012, Brandon Allbery wrote:

Is looking up a missing key in a Map an exception?

...

It is certainly an exceptional situation. You want to know the value that is associated with a key, but the answer is not the wanted value, but no value at all.

So you will insist that lookup when the key doesn't exist throw an exception? If not, why not? If we're going to make interfacing with the system as difficult and minetrap-strewn as possible, then let's cut to the chase and switch to Agda. Or we need to change a bunch of IO (Maybe x) to throw approved exceptions and make them suitably difficult to use for our walled garden instead of thinking about whether that's appropriate. Or, just maybe, we just need to stop thinking of it's-in-IO-it-should-throw-an-exception-at-every-opportunity-instead-of-being-*usable*. IO's enough of a sewer as it is without turning it into don't-think-about-it-just-hork-a-hairball too.

"exception" in what sense? Certainly not an exception in IO, since I do not like the implicitness of exceptions in IO. No I think, Maybe is a perfect return type for 'lookup'. What I want to say is, that Nothing is also an exceptional value.

(So, you just tossed in C-style without looking at the context?) 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. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

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