When using happstack, I find it really annoying to get a Prelude.head: null list error (or similar) in my web browser window because somewhere, some library used something unsafe -- and of course, since this is haskell, no stack trace.
if c-m-e can offer benefits around this, I would be very interested in adopting it.
That's what I meant with my post: Programming errors (like "head []") are not handled by control-monad-exception. As far as I understand, control-monad-exception makes _exceptions_ explicit in the type signatures, not programming errors. Why and how would you make possible programming errors explicit in the type? But for exceptions (e.g. "file could not be found") a detailed stack trace is not of much use. It seems again to me, that mixing of (programming) errors and exceptions is going on, and I assumed that the purpose of control-monad-exception is to separate them in a better way.
Sorry for the confusion, I never meant that c-m-e can show stack traces for asynchronous exceptions. It can not. I used the head of empty list error to draw a simile of why you would like to have a stack trace. I do not share your opinion that monadic call traces are not of much use. Your example looks a bit conspicuous to me. Consider a web application using HDBC to interface with a database, where a SQLError can arise and there is no way to find out where it is coming from. The safe-failure package (not officially released yet, but an early version is available in Hackage) provides monadic versions of several partial functions in the Prelude. An applicative interface is available which can make programming with those much more palatable. That means you can in effect obtain a stack trace for a head of empty list error. I would like, as much as anyone else, to see stack traces available for pure Haskell code. There are others already pursuing that goal, but as the situation stands now, stack traces are available only through expensive program transformations which cannot be used in production code. And I don't believe that situation is going to change in the close future. In contrast, monadic call traces have a simple implementation model by extending the bind operation with source locations. They are available now through the MonadLoc preprocessor which is not tied in any way to c-m-e. And moreover, they are unexpensive, can be used in production code, and can make your life much easier in many, many cases. I'm not sure if I managed to dispel your doubts, if not perhaps you could make your points more clear. Thanks, pepe